yes I understand the problem. I think I am willing to ignore it until we
switch to OSGi, It's very possible we will get a few
ClassNotFoundException when we do so and we will have to massage the
relevant pom.xml files. Tomorrow we should talk about how to start
integrating OSGi, probably using a Branch to minimize disruption but
have me starting to help you.
jerome
Sahoo wrote:
> 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
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>