After tracing the calls, we found out about the following behavior:
- when a request is triggered from an HTTP client (in other words, it goes through the web container), and we are in a servlet that talks to the PlatformMBeanServer, then the ContextClassLoader is the Web App classloader.
- when a request is triggered via JMX (e.g. via JConsole) and we are in the mbean, then the ContextClassLoader is an instance of EJBClassLoader (however, we are not sure where to position this classloader into this diagram:
http://docs.sun.com/app/docs/doc/820-4336/beadf?l=en&a=view&q=class+loader+glassfish)
Also, it turns out that the JAX-WS client uses a class called RuntimeModeler.java (see
http://fisheye5.cenqua.com/browse/jax-ws-sources/jaxws-ri/rt/src/com/sun/xml/ws/model/RuntimeModeler.java?r=1.20). At line 276, we see:
return Thread.currentThread().getContextClassLoader().loadClass(className);
So, we see that when we invoke the mbean from JConsole, the classes generated from JAX-WS cannot be loaded by RuntimeModeler.
To fix this, we added the following line in our mbean:
Thread.currentThread().setContextClassLoader(c1.getClass().getClassLoader());
where c1 is an instance of a class that belongs to the web module.
This works, but we are not sure whether this is an appropriate thing to do and have not completely understood how the MBeanPlatformServer works in Glassfish 2.1. Any feedback, comment and additonal information would be more than welcome :-).
Cheers,
Olivier
[Message sent by forum member 'oliechti' (olivier.liechti_at_wasabi-tech.com)]
http://forums.java.net/jive/thread.jspa?messageID=368566