Avoid ClassNotFoundException in JMX call via JVisualVM due to custom exception class

Question

Our application exposes some methods via JMX, which we invoke using JVisualVM.

This works well normally, but sometimes a method call will abort with an exception inside the application. In that case, instead of showing the error message from the exception, JVisualVM shows an error message

java.rmi.UnmarshalException [...] error unmarshaling return; 
nested exception is: java.lang.ClassNotFoundException [...]

This is rather unhelpful and confusing; we would like JVisualVM to show the real error message.

What we have found so far:

It seems that JMX will serialize and deserialize any exception thrown during a call. In our case however, the exceptions are custom exceptions which are not part of the JDK. Thus when invoking the methods via JVisualVM, JVisualVM cannot show the exception because deserialization fails due to the unknown custom exception class.

Right now, as a workaround we wrap all methods exposed via JMX in a try-catch block which just does

    throw new RuntimeException("Error invoking method:"+e);

This works, because it converts any exception to a string, but seems rather unelegant and verbose.

• Is there some generic way to tell JMX to not serialize exceptions? Something like "always convert exceptions to strings"?
• We use Spring's MBeanExporter. Is there maybe a mechanism in Spring to handle this?

Edit

We know that we could configure JVisualVM to load the classes in question. However, we would like JVisualVM to work without a special config. Also, it may run an a system where the application code is not even available.

Answer 1

Can you try playing with -Djava.rmi.server.codebase on JVisualVM so it can load the exception classes from the remote JVM?

Edit: If you don't want to do that, you could use an aspect to do the equivalent of your try-catch block. Then you only need it in one place. Spring AOP would make that quite easy if you're already using Spring.

Answer 2

Take a look at java.io.Serializable. you can implement an optional method called writeReplace that can be placed in your custom exceptions. Return a generic exception with the original message. When the exception is serialized, it will send the generic. Or you could send a string too, but I'm not sure if that will work well with VisualVM. I guess it depends on how strict the data checking is.

Serializable classes that need to designate an alternative object to be used when writing an object to the stream should implement this special method with the exact signature:

ANY-ACCESS-MODIFIER Object writeReplace() throws ObjectStreamException;

===== Update =====

Got it. 3rd party libraries.... Summarizing.... The challenge here is that calling setAttribute[s] and invoke on MBeans through JVisualVM results in exceptions being thrown that are of types not available JVisualVM's classpath.

If you implemented some sort of interceptor on your MBeanServer, it could trap any thrown exceptions (perhaps any exception with a class name not starting with java. or javax. and re-throw them as RuntimeExceptions with a very rich error message representing the original exception. (If useful, you could even include a string rendering of the stack trace). This is basically what you're doing now except it has the virtue of being centralized in one place and has no reliance on how you implement your classes.

Although MBeanServer interceptors are still absent from the standard JMX specification, you can mimic them by creating your own MBeanServer implementation that simply delegates to the real MBeanServer, but for setAttribute[s] and invoke calls, you can override with the "catch-and-rethrow" technique. It might sound like major surgery, but sticky issues with complicated application-server JMX implementations aside, it's actually fairly straight forward.

See this stackoverflow post and this gist for an example.

.....having said that, you are using Spring and you can specify the exact MBeanServer instance where your MBeans are registered, as well as the MBeanServer that is exposed to the JMXConnectorServer being used by JVisualVM. So it would be simpler to:

1. Use the MBeanServer wrapper idea outlined in the gist, construct it in Spring, injecting the real MBeanServer as the delegate
2. Reference the wrapper bean in your Spring JMX exporter.
3. Reference the wrapper bean in your JMXConnectorServer.

If your using the default JMXConnectorServer that bootstraps automatically, you would need to switch to using a Spring defined one.

The Spring based approach has the added benefit that only remote MBeanServer calls (like JVisualVM calls) will experience the exception rewriting, while internal calls in your application will get the real exception since they can go directly to the real MBeanServer.

===== One More Update =====

Spring JMX support does actually have an MBean interceptor implementation. I did not know about it, but as I was thinking about this issue, it sounded like something Spring would implement, and there it is.....