Hi,
Łabno, Bernard wrote:
> Indeed your explanation was very useful, but what shall I do exactly now ?
If your app doesn't set the context classloader, then it is a GlassFish
or Axis (hopefully Axis :-)) issue. I'm not sure it will work but you
might make sure, when the Servlet.destroy() (if you use Servlet) unset
the Context Classloader, so when the application is undeployed, the
context is reset (but to be honest I really don't think it is viable
solution).
> Shall i somewhere in constructor of ejb unset contextClassLoader ?
Could it be a bug in Axis? Is your application set the context
classloader or you get the exception because of Axis? Those bugs are not
simple to track (at leats for me :-)). Last time I've to instrument the
JDK's Thread classes to find who, inside GlassFish, was configuring the
context classloader (was the ORB, but that issue has been fixed now).
Are you able to reproduce the problem without Axis?
-- Jeanfrancois
>
>> To add to this, we usually see that situation when an application invoke
>> the Thread.setContextClassLoader(WebAppClassloader) and forgot to unset
>> it when the WebApplication is stopped/undeployed. Next time the thread
>> is re-used the exception will show up.
>>
>> Hope that help.
>>
>> -- Jeanfrancois
>