[jboss-dev-forums] [JBoss Microcontainer Development] - VFS deployers and CL behaviour

[flavia.rainone@jboss.com]

During debugging of the class pool/vfs tests, two things called my attention:

- 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.

- I noticed that the PackageVisitor.determineAllPackages method returns the META-INF as an exported package name. Is this filtered out sometime later during execution?

View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4267533#4267533

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