-
15. Re: Module.getModuleForClassLoader()
"kabir.khan@jboss.com" wrote:
I've added ClassLoading/Module.getClassLoaderForModule()
https://jira.jboss.org/jira/browse/JBCL-80
http://fisheye.jboss.com/changelog/JBossAS/projects/jboss-cl?cs=83424
http://fisheye.jboss.com/changelog/JBossAS/projects/jboss-cl?cs=83425
This doesn't look valid.
Otherwise there would already be a public method Module::getClassLoader.
Since that's exactly what you expose, just making it harder to find. :-) -
16. Re: Module.getModuleForClassLoader()
"alesj" wrote:
Otherwise there would already be a public method Module::getClassLoader.
Since that's exactly what you expose, just making it harder to find. :-)
Errrm, yes :-)"alesj" wrote:
This doesn't look valid.
I can move it, are you saying we should not expose it? This functionality is crucial for me for the reasons explained... -
17. Re: Module.getModuleForClassLoader()
You are kind of both right. :-)
The functionality is ok since it is protected by a permission check.
But there's no reason to maintain a map of module->classloader.
The module already has a protected getClassLoader() method.
The map exists the other way around classloader -> module
to avoid having to iterate over all the domains/modules.
The module doesn't have a classloader until its dependencies are satisfied
and the module is asked to construct the classloader, which is why there is a callback
to maintain the map.
I've tidied this up in 2.0.x and trunk