dev@glassfish.java.net

Re: [v3] exporting all Metro packages for OSGi

From: Sahoo <Sahoo_at_Sun.COM>
Date: Wed, 27 Aug 2008 22:52:33 +0530

Richard S. Hall wrote:
> 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.
>
That's exactly what we do in one of the class loaders in the delegation
chain of WebAppClassLoader. It's a kind of extender pattern that we use.
During bundle installation, we look for META-INF/services in a bundle.
That information is later used during loadClass or getResource. So, I am
actually to see this exception. I think we need a simple test case to
proceed.

Fabian, can you put together a test case and send me?

Thanks,
Sahoo