Re: [wildfly-dev] Debugging transformers and reverse controller check

Hi, I am forwarding this to the list since it will hopefully help others as well. Now, the main concept behind this is that CLI scripts written against for example AS 7.1.3 should still work against WildFly 8. The way we did this is the reverse controller checks (crap name, but they were written very quicky before a deadline). They hook into the transformers tests where you boot up the main and legacy controllers with some xml, i.e. not the reject variety which boots them up with an empty one. So what happens in a typical transformers test when you call KernelServicesBuilder.build() is 1) The xml is parsed into ops by the WF 8 parser 2) We boot up the main controller with the current WF 8 classpath 3) The ops from 1) are transformed into the model version of the legacy controller 4) We then boot up the legacy controller using the old jars using the ops from 3 5) We then boot up another ‘main controller’, using the current WF 8 classpath using the ops from 3- this controller is not used in the rest of the tests, only the ones from 2 and 4 6) Compare the model in the controller from 5 with the model from the controller in 2 The theory is that the ops parsed in 3) are something which would have worked for the old AS version and should still work today, which is what step 5 checks. LegacyKernelServicesInitializer has a few methods to control what happens at 5 when it cannot work perfectly: .skipReverseControllerCheck() - this turns off step 5 totally .configureReverseControllerCheck(AdditionalInitialization additionalInit, ModelFixer modelFixer) and .configureReverseControllerCheck(AdditionalInitialization additionalInit, ModelFixer modelFixer, OperationFixer operationFixer) The configure varieties are preferred to skip. I’ll try to explain what problems the different parameters to the configure methods are below. Pass in an AdditionalInitialization.MANAGEMENT, this in some cases is all you need to do if the main kernel services builder is configured with an AdditionalInitialization which does the runtime part of the tests, and helps avoid port conflicts etc. when starting the second controller in 5. In fact, I should probably have made sure that happens by default, at the moment it seems to use one which does the runtime part when .configureReverseControllerCheck() has not been called, or is called with a null additionalInit. If that does not solve it and you get a problem somewhere in ModelTestUtils.compare() this means that the ‘reverse controller’ booted, but its model differs from the main controller model. This can be fixed by passing in a ModelFixer to fix inconsistencies in the model of the ‘reverse’ controller before the comparison is done. This fixer will be used in step 6. For example, in some cases the ops for the legacy controller change the model slightly, which is often fine, and can be fixed this way. If the ‘reverse’ controller fails to boot in 5, put a logging breakpoint which prints the stack trace in AbstractOperationContext.executeStep() and figure out the offending operation(s). You can then use the OperationFixer to fix the offending operations. For Infinispan, I don’t remember the details but I think you had something called segments and now you have virtual-nodes (or the other way round), and some slightly complex conversion was done between the two. So if step 3 changed virtual-nodes in the ops to segments, and this is then attempted used in step 5 fixing these operations is a valid fix since segments is deprecated in the current model. On 19 Nov 2013, at 01:07, Richard Achmatowicz <rachmato(a)redhat.com&gt; wrote: