On Aug 27, 2008, at 7:08 AM, 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?
Your original message said that you were invoking Class.forName(String
name) which according to the Javadoc is identical to
Class.forName(name, true, currentLoader) where currentLoader is the
loader of the caller.
From the sounds of it, this is exactly what you want for internal
classes (same OSGi bundle).
You would only want to use the context class loader if loading classes
from the user's application. So it's worthwhile to look in detail at
your usages of Class.forName to distinguish between loading user
classes and loading internal classes.
Craig
>
>
> Fabian
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>
Craig L Russell
Architect, Sun Java Enterprise System
http://java.sun.com/products/jdo
408 276-5638 mailto:Craig.Russell_at_sun.com
P.S. A good JDO? O, Gasp!
- application/pkcs7-signature attachment: smime.p7s