VFS deployers and CL behaviour

[flavia.rainone]

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?

[alesj]

- 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

- 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? ;-)

[alesj]

"alesj" wrote:

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

But afair, vaguely, Adrian mentioned that both calls to resent are needed.
As things might break in any of the two used stages, and you need a proper cleanup.
If all things go OK, 2nd call is a noop, but you don't know if things will go well.

I guess Adrian can shed some more light on the subject. ;-)

[flavia.rainone]

"alesj" wrote:

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

Isn't there a better solution for this problem? I know can get rid of the overhead by mapping the module to the exported classes. But this means relying on implementation detail I shouldn't even be aware of.

"Ales" wrote:

How else would a call to ClassLoader::getResource("META-INF/some-config.xml") work? ;-)

But if somebody puts SomeClass.class in META-INF, the class loader will be able of loading META-INF.SomeClass. I know this scenario is totallly awkward and should never happen, but aren't we supposed to cover corner cases?

[flavia.rainone]

"Flavia" wrote:
But if somebody puts SomeClass.class in META-INF, the class loader will be able of loading META-INF.SomeClass. I know this scenario is totallly awkward and should never happen, but aren't we supposed to cover corner cases?

Kabir answered my question :):

"Kabir" wrote:
I think that would only work if the classes full name is META-INF.SomeClass, in which case it should actually be in that folder :-)