JMX Classpath Issues with JBoss plugin?

[aperezlo]

Hello all,

I'm wondering if any of you could shed a little light onto my problem. I have an EJB application that uses JMX. At one point, I try to use some of the JMX code that I have, and I run into a peculiar situation. I want to deploy this code in an instance of JBoss that's invoked by running the standard '$JBOSS_HOME/bin/run' script. While I'm developing, however, I take advantage of Eclipse debugging by using the JBoss Run/Debug configurations provided by the excellent JBoss plugin (JBoss-IDE v.1.5.0).

Here's the strange part. When I run JBoss from the plugin, my app works. When I run from the command line (w/ the 'run' script) it doesn't. I enabled remote debugging in the 'run' script, and used Eclipse's remote debugging to get some visibility into that process. It turns out that for some reason, when I run from within Eclipse, JBoss finds its own implementation of JMX, and that works, but when I run from the command line, JBoss uses Sun's implementation of JBoss, and that breaks. I checked the classpaths, and I don't have anything set in the JBoss configuration except the Java 1.5 JRE in the Bootstrap entries (i.e. no User Entries). The exception thrown is a ClassNotFound on some of one of my JMX beans.

So my question is: does anyone know of anything going on within the JBoss plugin or its Run/Debug configurations that would impact which versions of the JMX classes to load? Further, does anyone have any idea why the different implementations of JMX would behave differently?

Thanks very much for your help.

Cheers,

-Andrew

[aperezlo]

To anyone that has the same problem, here's what I figured out:

I had been following the advice of the Wiki here and getting a handle on the JBoss MBean server by calling:

(MBeanServer) MBeanServerFactory.findFactory(null).get(0);

That worked fine from within Eclipse, but when run outside Eclipse, Sun's JVM MBean server was the first in the list returned, and the classes I needed were only available within the scope of the JBoss class loader.

The solution, which is less than perfect because it uses JBoss specific code, was to get a handle to the JBoss server using this method:

org.jboss.mx.util.MBeanServerLocator.locateJBoss();

I hope this helps someone!

Cheers,

-Andrew