"flavia.rainone(a)jboss.com" wrote : | - the call to Module.reset() is duplicated.AbstractLevelClassLoaderSystemDeployer.removeClassLoader() directly invokes reset; and VFSClassLoaderDescribeDeployer invokes it indirectly, as it invokes ClassLoading.removeModule() which in turn invokes reset. | Is this expected? In the case of the class pools, RegisterModuleCallback is invoked by ClassLoading.removeModule(). At this point, ClassLoading hasn't reset the module yet, but AbstractLevelCLSystemDeployer has already done it. Despite that, RegisterModuleCallback needs to retrieve the package names, thus causing the module to reload the capability collection.. To get rid of this overhead, of course I could add a map to keep track of the package names associated with a module, avoiding the call to module.getPackageNames(). But isn't it expected that other module registries being notified of a removeModule may want to use the capability collection of the module as well? If the answer is yes, I think the module shouldn't be reset at this time. | This is an old discussion, that as I see it now, never got properly resolved: http://www.jboss.org/index.html?module=bb&op=viewtopic&t=146461 "flavia.rainone(a)jboss.com" wrote : | - I noticed that the PackageVisitor.determineAllPackages method returns the META-INF as an exported package name. Is this filtered out sometime later during execution? How else would a call to ClassLoader::getResource("META-INF/some-config.xml") work? ;-) View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4267550#... Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&a...