dev@glassfish.java.net

Re: [v3] exporting all Metro packages for OSGi

From: Richard S. Hall <heavy_at_ungoverned.org>
Date: Wed, 27 Aug 2008 12:50:35 -0400

Fabian Ritzmann wrote:
> On 27. Aug 2008, at 16:40, Sahoo wrote:
>> Fabian Ritzmann wrote:
>>> On 27. Aug 2008, at 13:49, Sahoo wrote:
>>>
>>>> No, I still don't understand why we are seeing failures. My
>>>> understanding is that Metro is a OSGi bundle and some code in that
>>>> OSGi bundle is attempting to load another non-exported class from
>>>> the same OSGi bundle using a variant of Class.forName() that does
>>>> not take any classloader as argument. In such a case,
>>>> Class.forName() uses caller's classloader, which is the classloader
>>>> of the Metro bundle. Such a class loader should be able to load any
>>>> class that's part of Metro bundle.
>>>>
>>>> There are two assumptions here:
>>>> 1. Class being loaded is part of Metro OSGi bundle.
>>>> 2. No classloader is passed to Class.forName().
>>>>
>>>> Is any of them wrong?
>>>
>>> Both assumptions are correct.
>> Looking at your recent emails, I don't understand how you concluded
>> both the assumptions were correct. I do think the code passes
>> Thread's context class loader while calling Class.forName().
>> Otherwise, how is the WebappClassLoader coming into picture? Clarify
>> this please.
>
> I'm sorry, I should have double-checked. You are right, this code is
> actually invoking Class.forName("classname", true, classloader) where
> classloader is Thread.currentThread().getContextClassLoader().
>
> So what would be the right thing to do instead?

For an OSGi-specific solution, you could create a class loader that
knows how to probe existing OSGi bundles for their META-INF/services
metadata and then loads the needed class through Bundle.loadClass(), in
which case the class would not have to be exported.

There is a potential issue here in the future is new VM module
mechanisms change how visibility of classes works from a class loader,
but this is an unknown at this point.

-> richard

>
> Fabian
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>