-
Feature Request
-
Resolution: Done
-
Major
-
3.0.0.Alpha10
-
None
Rejection-style transformer tests assumes each operation generated by parser can be executed on its own, outside of a batch This has been generally the case until introduction of capabilities. If a subsystem add operation references a capability introduced by subsequent add operations the rejection test cannot be bent over to pass. This is an issue of the test framework, during normal boot the operations are batched and this is not a problem.
An example of this can be found in the singleton subsystem:
/subsystem=singleton:add(default=mypolicy)
/subsystem=singleton/singleton-policy=mypolicy:add(...)
So the test fails for the 1st parsed operation
{
"operation" => "add",
"address" => [("subsystem" => "singleton")],
"default" => "simple"
}
with
java.lang.AssertionError: WFLYCTL0369: Required capabilities are not available:
org.wildfly.clustering.singleton.policy.simple; There are no known registration points which can provide this capability.
at org.junit.Assert.fail(Assert.java:88)
at org.junit.Assert.assertTrue(Assert.java:41)
at org.jboss.as.model.test.ModelTestUtils.checkOutcome(ModelTestUtils.java:121)
at org.jboss.as.model.test.ModelTestUtils.checkFailedTransformedBootOperations(ModelTestUtils.java:509)
at org.wildfly.extension.clustering.singleton.SingletonTransformersTestCase.testRejections(SingletonTransformersTestCase.java:130)
at org.wildfly.extension.clustering.singleton.SingletonTransformersTestCase.testRejectionsEAP700(SingletonTransformersTestCase.java:105)
I assume this will be more of a problem when testing EAP 7.2 to 7.1 transformations since there aren't many subsystems supporting capabilities in 7.0 apart from the singleton subsystem.
- blocks
-
WFLY-7683 Remove workarounds for WFCORE-1892 rejection-style tests
-
- Closed
-
