ClassCastException when accessing user-defined class via JMX

Question

I'm monitoring, via JMX, a servlet running in Tomcat with another servlet running in the same instance of Tomcat. When I setup the get()s to return standard Java datatypes( String, int, byte[], etc. ), this works fine. But when I use a user-defined class, I get a ClassCastException which gives this message:

java.lang.ClassCastException: blah.My_UserDefinedClass cannot be cast to blah.My_UserDefinedClass

I'm fairly sure this is because of the different class loaders at the instrumentation and at the management layer ( the monitored servlet and the monitoring servlet, respectively ). I've double-checked the .jar file that contains the user-defined class for each servlet and both jar files are identical to each other.

I'm using standard MBeans, and have set up the monitored servlet to return this attribute:

public interface MyMonitorMBean
{
    public My_UserDefinedClass getAllData();
}

implementation:

public class MyMonitor implements MyMonitorMBean
{
    private My_UserDefinedClass mAllData;

    @Override
    public My_UserDefinedClass getAllData()
    {
        return mAllData;
    }   
}

Code in management servlet to access this data:

private void getAllDataFromMBean()
{
    try
    {
        // this line generates the ClassCastException
        My_UserDefinedClass allData = (My_UserDefinedClass)mMBS.getAttribute( mObjectName, "AllData" );
    }
    catch( Exception e )
    {
    }
}

While I could generate multiple get()s with each sending a standard Java datatype, I would like to build/use my own POD/POJO class that encapsulates all of the various standard bits and bobs ( which are standard Java datatypes ) that I want to send back so that I can get my data in a single call.

Any thoughts?

Thanks,

Bill

Using tomcat7, java6, windows xp, 32bit

Answer 1

This may work for you. You need to set the context class loader of the thread [temporarily] to the class loader of the MBean. You can determine this by requesting the class loader instance from the MBeanServer.

private void getAllDataFromMBean()
{
    try
    {
        final ClassLoader originalClassLoader = Thread.currentThread().getContextClassLoader();
        try {
            ClassLoader mbeanClassLoader = mMBS.getClassLoaderFor(mObjectName);
            Thread.currentThread().setContextClassLoader(mbeanClassLoader);
            My_UserDefinedClass allData = (My_UserDefinedClass)mMBS.getAttribute( mObjectName, "AllData" );
            // Process allData here
        } finally {
            Thread.currentThread().setContextClassLoader(originalClassLoader);
        }
    }
    catch( Exception e )
    {
    }
}

==== UPDATE ====

There is also a closely related question more comprehensively answered here: ClassCastException when casting to the same class.

==== UPDATE ====

I am not totally clear on the exact setup you have, but one way or the other, you definitely have a classloader issue where, at runtime, you have [at least] two different classloaders that have loaded My_UserDefinedClass.

These are some options:

Lifecycle

Make sure that the class defining getAllDataFromMBean is classloaded in the same classloader so there is only one classloader. (Might be tricky)

Alternatively, put the jar containing the class into the system classpath before it is ever loaded. (i.e. the boot classpath, or system classpath)

Reflection

There is a core issue with classloaders here because your getAllDataFromMBean method is in a class which will have triggered a load of My_UserDefinedClass as soon as it was loaded, so right off the bat, you have two different classloaders and therefore incompatible types. Accordingly, since the underlying values are all standard java types, you could access the instance reflectively.

** Generification **

Rather than creating a user defined class for your values, keep them in a name/value map. That way, all the data being passed is in core java types.

** Externalization **

If you force the user defined instance to be serialized (say to a byte[]) and then deserialize it on the reading end, you will bypass this problem.

** Open Types **

This is the solution I think is the best. Define your type as a CompositeData. That way, there is no custom class dependency at all. This has added advantages like the fact that you can display the values in a remote JMX client (like JConsole etc.) that does not even have the custom class in it's classpath.

//Nicholas