Richard S. Hall wrote:
>
>
> 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.
In addition to having the ability to all classes exported by other
bundles, WebappClassLoader also has the extender support built into it.
Whoever gave you the explanation might have missed this extra detail.
That's exactly why I fail to understand the situation. I have asked for
a test case. I will take a look at it and let others know what I observe.
Thanks,
Sahoo