Great. It works now.
MBeanServer server = (MBeanServer) MBeanServerFactory.findMBeanServer(null).iterator().next();
Then, invoke through the server works fine.
The MBeanServerFactory came from lib/jmxri.jar, and somehow it can access jars from lib/ext. But, from EJB, it cannot access the jars from lib/ext. How is that possible?
The parent of the ClassLoader of EJB can load the jars from lib, and the parent of the ClassLoader of lib can load jars from lib/ext????
I'm not sure I understand the problem.
What is the error you see?
There are three levels of classloader
lib - created by the manifest of run.jar
lib/ext - created by jboss.conf
ejb - the thread context class loader
I think I solved that funky problem.
From run.jar of the jboss bin directory, it has this manifest attribute:
Class-Path: ../lib/jmxri.jar ../conf/ ../client/jboss-client.jar ../lib/jaas.jar ../lib/jdbc2_0-stdext.jar ../lib/jboss-jaas.jar ../lib/jaxp.jar
So, the default classloader loads the jmxri.jar.
The parent of MLet classloader is the default classloader.
This MLet classloader loads all jars from jboss where ./ is the lib/ext directory.
<!-- Place the config directory in the classpath -->
So, those jars from lib/ext ask the default classloader before MLet classloader. Because the MLet's parent is the default classloader, jmxri.jar can access the classes from the lib/ext jars.
The EJB's classloader must not be MLet. Its parent classloader must be the default classloader.
So, EJB class can access those classes from jmxri.jar.
To summarize the point, the classes loaded by the parent classloader can use the classes loaded by its child classloader. And, vice-versa.
But, the classes loaded by one child classloader cannot use the class loaded by another child classload although they have same parent classloader.
This is standard java classloader behaviour.
JBoss3.0 changes this rule with the UnifiedClassLoaders.
All child classloaders are available from other childs
of a global parent.
It isn't standard java classloading, but it simplifies
the packaging and allows other performance enhancements.
Actually, as a further clarification
Under standard java, a parent cannot access a child's
classes during dynamic classloading, unless
the child's classloader is set as the thread's classloader.