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#...
Reply to the post :
http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&a...