"adrian(a)jboss.org" wrote : | These tests should be using the classes in target/classes compiled from src/main | with the deployment constructed using multiple bases. | i.e. using the AssembledDirectory vfs | | Major Problems I see: | | 1) Use of ClassLoaderSystem.getInstance() | Each test should be constructing its own ClassLoaderSystem not | sharing the default one. Using the default one is bound to introduce leaks across tests. | See for example the ClassLoaderDependenciesTest in deployers-impl | on how to do this. | | 2) Isolated classloading. It should also be setting the DefaultDomain | in its own ClassLoaderSystem to be BEFORE_BUT_JAVA_ONLY | again see ClassLoaderDependenciesTest | otherwise you're going to load classes from the testsuite classpath | rather than the deployment so there's no real test at all | Yup, it's on my todo list. That's been puzzling me from the beginning. But since it worked, in both - IDEA and maven - I didn't go and investigate in details. :-) "adrian(a)jboss.org" wrote : | 3) BeanScanningDeployer using setRelativeOrder is a hack | and the component handling is fundamentally broken/brain dead. | | | | public BeanScanningDeployer(KernelDeploymentDeployer kdd) | | { | | super(AnnotationEnvironment.class); | | setInputs(BeanMetaData.class); | | setOutput(BeanMetaData.class); | | if (kdd != null) | | setRelativeOrder(kdd.getRelativeOrder() + 10); | | else | | setRelativeOrder(getRelativeOrder() + 10); | | } | | | | This breaks the orthogonality of the deployers. One deployer should | not depend upon another. This needs doing in a different way. | | This can be seen further with the "mapComponents" stuff. | This deployer should either be a component deployer or a top level deployer | not mixing/matching and hacking in some bizarre way. | | It certainly shouldn't be creating components by delegation to a different deployer that has run earlier. | | Iteration and delegation, {insert explitive here :-) } | | | for (BeanMetaData bfb : bfBeans) | | { | | KernelDeploymentDeployer.addBeanComponent(unit, bfb); | | | | Who knows what happens when addBeanComponent throws an error? | | With these current hacks it is impossible for me to insert some extra behaviour | between these deployers because it is doing a stupid almost indeterminate dance. | Nor can I replace one of these deployers with alternate behaviour because | they are too tied together. | (A bit of cardboard posting ... again) OK, just saw your 2nd post to this issue. :-) "adrian(a)jboss.org" wrote : | 4) Debugging | | Even if I do enableTrace("org.jboss") | I get no inclination why this test is failing. | Where is the debug information? | Coming up. ;-) "adrian(a)jboss.org" wrote : | 5) Others | | There's probably more wrong? But this is just from a basic look. | e.g. why do these tests depend upon the VFS anyway? | | As far as I can tell, these tests would work just as well under the Mock classloading | in deployers-impl if written properly? OK, I'll leave the current one's as they are, and add a few there. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4154311#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...