dev@glassfish.java.net

Re: [v3] exporting all Metro packages for OSGi

From: Jeanfrancois Arcand <Jeanfrancois.Arcand_at_Sun.COM>
Date: Wed, 27 Aug 2008 10:49:54 -0400

Salut.

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().

[Not related to OSGi]

Doing that is quite dangerous if the context classloader is the
WebappClassloader. Why? Because the WebappClassLoader is active only
when the application associated with that classloader is deployed. When
the application is undeployed, the WebContainer marks that Classloader
as dead. An example is describe here:

https://glassfish.dev.java.net/issues/show_bug.cgi?id=5628

In that case, I suspect the Admin CLI is caching a WebappClassloader and
try to re-use that classloader after the associated application gets
undeployed, producing the ThreadDeath exception

If I follow you correctly, Metro will suffer the same issue if the
context classloader is cached or candidate to be re-used after the
application has been undeployed....

-- Jeanfrancois



>
> So what would be the right thing to do instead?
>
> Fabian
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>