Jerome,
I think I know why others have not noticed it so far. There is a bug in
HK2's class loader which re-exports some imported classes. As per one of
your recent emails to dev alias (subject Re: [blocking] Not able to
deploy ROR applications), you have changed HK2 class loading policy not
to re-export classes that belong to imported modules. There are
situations where the implementation allows imported classes to be
re-exported. This is because of the following sequence of events:
1. org.glassfish.internal.api.Init is requested to be loaded using the
private class loader(ModuleClassLoader) of kernel module.
2. Since kernel depends on internal-api, this class loading is
sucessful. Now this class is added to the loadedClasses cache of this
ClassLoader.
3. While loading ServiceHookup.class, private class loader of
glassfish-naming has to load Init.class as well. So, it calls loadClass
using the public class loader of each of the imported modules. This
eventually calls
ClassLoaderProxy.loadClass("org.glassfish.internal.api.Init", false,
false). This method first checks cache of loaded classes. When this
method is called using the kernel module classloader, it finds the class.
As a net effect, even when we wanted not to re-export Init.class, it
gets loaded using the public class loader of glassfish-naming module.
This is a serious bug. As long as this bug exists, we don't know about
the correctness of our module dependencies.
Thanks,
Sahoo
Sahoo wrote:
> ServiceHookup.class in glassfish-naming implements Init.class which
> belongs to internal-api module. Then, why does glassfish-naming module
> does not import internal-api module? Because of transitive dependency,
> maven is able to compile the code, but I don't see the import-bundle
> header correctly generated.
>
> Thanks,
> Sahoo
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>