-
1. Re: removeClassLoader operation in jmx console
dimitris Mar 13, 2005 1:15 PM (in response to balteo)This doesn't seem like a method that you can remotely call...
-
2. Re: removeClassLoader operation in jmx console
balteo Mar 13, 2005 1:34 PM (in response to balteo)Thanks for the reply Dimitris,
Is there a surefire way to know which method one can invoke in the jmx console?
Julien. -
3. Re: removeClassLoader operation in jmx console
dimitris Mar 13, 2005 2:26 PM (in response to balteo)Not really. The jmx-console is generic but at the same time "dumb" because it just uses the metadata from each MBean in order to present the exposed attributes and operations.
What each operation does, whether its parameters are serializable or not, or what each attribute means, is really something defined by the MBean writer, and we know that in jboss everyone can write and extend jboss with her own mbeans. There is no formal way to know this info.
So each MBean writer should have a section in her own documentation providing this information. This is often the case with the various jboss subsystems (e.g. JCA will let you know what are the related MBeans and what each attribute means, give or take :)
What we don't have, is a comprehensive list of things of interest for the jboss administrator.
The new jboss admin console which is under development will offer a more "administrative" and functional view to the multitude of functionalities available with jboss.
Hope that helps :) -
4. Re: removeClassLoader operation in jmx console
balteo Mar 13, 2005 2:45 PM (in response to balteo)Thanks for the detailed reply.
Julien :-) -
5. Re: removeClassLoader operation in jmx console
genman Mar 15, 2005 5:29 PM (in response to balteo)
You could create your own MBean (that's perhaps remotely accessible or not) that, given a String, calls the JBoss MBean for you. -
6. Re: removeClassLoader operation in jmx console
starksm64 Mar 15, 2005 5:51 PM (in response to balteo)Removal of a class loader from the ULR is not supported from the jmx-console, remotely in general, and is a questionable thing to do as you are essentially fracturing the type system associated with the removed class loader. Every class loaded by that class loader remains bound to it as long as there are references to the classes or class loader itself. Recycling of classes needs to be done via redeployment.