[jboss-dev-forums] [Design the new POJO MicroContainer] - Re: Annotation Tests in deployers-vfs

[alesj]

"adrian at 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 at 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 at 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 at 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#4154311

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4154311