Sahoo wrote:
> 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.
But the description of WebappClassLoader that has been offered to me is
that it loads from all exported packages, which explains why service
providers must export their impl class. This discussion was about
avoiding exporting the impl class.
-> richard
>
> Fabian, can you put together a test case and send me?
>
> 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
>