Sahoo wrote:
> 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.
If that is the case, then I am in agreement with you, it doesn't make
sense that it could not load private classes from the bundle.
Still, I do have some concerns about loading from exported packages.
Does this mean that it uses DynamicImport-Package or is it just
analyzing the bundle export metadata?
-> richard
>
> 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
>