I found a random bug in ClassPool project. Check this scenario: 1. An ear with two wars is created and deployed. 2. When the test invokes ClassPoolRepository.registerClassLoader, passing the ear class loader as an argument, it will trigger the creation of the ClassPool corresponding to the ear module. This creation is performed by JBossClDelegatingClassPoolFactory 3. The factory will perform a series of steps: creating the parent class pools(a), then creating the bootstrap classpools (b), creating the classpool domain(c), and finally creating the requested class pool itself(d). 4. In the given scenario, the class loader has no parent, so there is no parent class pool to be created (a). 5. When the factory reaches the bootstrap classpool creation is the problem. The "bootstrap" modules are the modules that have been registered in the RegisterModuleCallback but have no corresponding classpool yet. So, in the given scenario, the factory will iterate for a collection containing both war modules, as none of them has the corresponding classpool created yet. 7. Starting with the first war, this classpool creation will result in recursive call to JBossClDelegatingClassPoolFactory. It will again iterate for the unregistered classpool collection, which now contains only the other war. Again, we have a recursive call to create the classpool for this second war. 8. Reaching the second war, the factory will have no "bootstrap" classpools to create. So it will move on to step (c), creating the class pool domain. But the domain of the war is the ear classloader. So, it will create the classPool for the ear that was requested during step 2. It will then create the classpool for this second war and return. 9. Now, once the recursive call is returned to the context in which the classpool for the first war is created, the "bootstrap" cp creation is considered finished(b), and it will move on to creation of the domain classpool(c). Again, the domain is the ear classloader. As this step invokes ClassPoolRepository.registerClassLoader, it will be able of recognizing that a classpool for this ear has already been created, during the previous step. 10. Returning to the original context of the CP factory, in which the cp for the ear was being created. This step will try to create a CP for the second "bootstrap" module, that is the second war. Again, as this invokes ClassPoolRepository.registerClassLoader, it will recognize that this CP is created and consider this done (b). 11. Finally, the ClassPoolFactory finds the CP domain of the ear (app classLoader) (c) and creates the CP corresponding to the ear module (d). The problem is that this ear has already been created during step 8. So, I thought that this "bootstrap" cp creation was not needed. We first create the parent pools and then the domain pools, so why would we need to create other pools? I resolved the problem getting rid the "bootstrap" cp creation. Unfortunately, this breaks the testNonDeploymentModule test. This test deploys a jar that contains the following beans.xml file: <deployment xmlns="urn:jboss:bean-deployer:2.0"> | | <classloader><inject bean="anys-classloader:0.0.0"/></classloader> | | <classloader name="anys-classloader" xmlns="urn:jboss:classloader:1.0" import-all="true"> | <capabilities> | <package name="org.jboss.test.deployers.vfs.reflect.support.web"/> | </capabilities> | <root>${jboss.tests.url}</root> | </classloader> | | <bean name="AnyServlet" class="org.jboss.test.deployers.vfs.reflect.support.web.AnyServlet"/> | | </deployment> | The module corresponding to anys-classloader is registered in the RegisterModuleCallback and would result in a CP creation during the "bootstrap" CP creation. As I commented out that part of the code, this test no longer works. I was wondering is there is any way of identifying that specific type of scenario. If I could do that, I would generate the "bootstrap" CP only for "non-deployment" modules. This would avoid the problem in the scenario I described above without breaking testNonDeploymentModule. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4266431#... Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&a...