This is the lifecycle of module resgistry and class pools creation today: 1. Use RegisterModuleCallback as a ModuleRegistry so it can be notified of modules being deployed and undeployed 2. RegisterModuleCallback.addModule adds the module to an unrgisteredModules collection. 3. When ClassPoolRepository.registerClassLoader(CL) is invoked, this will trigger a call to JBossClDelegatingCPFactory. 4. The factory will invoke RegisterModuleCallback.registerModule. At this point, the module is going to be reomved from the unregisteredModules collection and added to the registeredModulesCollection. 5. The factory will iterate through all unregisteredModules of RegisterModuleCallback (the so-called "bootstrap" modules) in order to create the "bootstrap" CPs. Ales suggested me that I got rid of this way of creating ClassPools, making sure that the ClassPool is created by RegisterModuleCallback.addModule. This way, we get rid of the unregisteredCP collection and we get rid of the "bootstrap" CP creation that causes the aforementioned bug. Unfortunately, that doesn't work :(. I need the ClassLoader in order to create the ClassPool, and at the point RegisterModuleCallback.addModule is invoked the class loader associated with the module is null. I'm assuming that there is no easy way of filtering out the modules I need to filter. So I'll use the recursion structure itself to deduct when the module needs to be filtered out and I'll abort the CP creation for those modules. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4266616#... Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&a...