On 27. Aug 2008, at 17:49, Jeanfrancois Arcand wrote:
> Salut.
Moi.
> Fabian Ritzmann wrote:
>> 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....
Alright, that is a valid concern, in particular because that class
loader gets stored in a member variable. On the other hand, I don't
believe it is ever used again after all the service implementation
classes were loaded. That step is happening when the web service
servlet gets initialized, i.e. we should be safe. I'll still
investigate if we can do something to make sure we don't introduce
bugs there in the future.
Fabian