dev@glassfish.java.net

Re: webapp classloader and JMX

From: Kedar Mhaswade <Kedar.Mhaswade_at_Sun.COM>
Date: Thu, 04 Dec 2008 15:02:21 -0800

I am copying Eamonn (JMX Spec lead) to offer any insights he may have, but
I think you can resort to a solution where the MBeans are "packaged"
as part of the same web application that you want to configure.

It's not terribly clear what you mean by "JMX to reconfigure the service".
But if you want the JMX MBean "code" to be loaded by the web-app classloader,
you can try packaging the MBeans in WEB-INF/lib/*.jar. Since the
web-app classloader will load classes from here, they should be available
to your MBeans (I believe).

-Kedar

Fabian Ritzmann wrote:
> Hi,
>
> I am prototyping some code that reconfigures a web service at runtime.
> The reconfiguration is triggered by JMX. I just bumped into an issue
> with class loading in that case. A web service that is running in a web
> app inside GlassFish will use the web application class loader to load
> classes. But when I am using JMX to reconfigure the service, the web
> service code will run with the JMX class loader. This does not work of
> course because the JMX class loader does not know anything about the
> classes in the web application. I would need to be able to run the
> reconfiguration within the context of the web application. Right now I
> see two options:
>
> - Pass the webapp classloader into the JMX agent and set it as the
> Thread context classloader. I am already passing the classloader into
> the agent actually so that would be quite feasible. I am not sure the
> JMX agent would be happy about running with a non-JMX classloader. Also
> some of the code retrieves the classloader from Class.getClassLoader()
> instead of the Thread.
>
> - I studied M-Lets and from what I understand they are primarily used to
> load MBeans from remote URLs. I am not quite clear if they could also be
> used to set the classloader on the one MBean that runs the
> reconfiguration in the same thread.
>
> I would appreciate any insights. I haven't really found much material on
> that particular problem.
>
> Fabian
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>