Skip navigation
There's a plugin for NetBeans that supports the JMX API. It allows you to create and modify JMX MBeans through a wizard, to create unit tests for them, and to run an application and simultaneously attach to its JMX instrumentation. My colleague Jean-François Denise writes about this and more in a recent blog entry, with pointers to some excellent tutorials.  

Ron Bodkin has written an excellent, detailed articleabout using the Glassbox Inspectorproject. This combines AspectJ and JMX technologies to add monitoring to applications in a clean and modular way.

I particularly like this style of article, where extended code extracts are used to present something really useful rather than just a toy example. The alternating text and code reminds me of Literate Programming.

While much has been written about the possible abuses of AOP, most of it focuses on cases where AOP is used to change the visible semantics of a program, so what you see is not what you get. Most people agree that using AOP to add monitoring or logging to a program is an excellent fit (with the usual warning to beware of performance impact). This article shows how this can be done cleanly and transparently. It provides one good answer to a question that often arises about using JMX technology: how do you link the application's objects to the JMX instrumentation without breaking modularity? You don't want to hardwire JMX API references into application classes, and you don't want your JMX MBeans to be reaching into the innards of your application to pick out the objects they need. (There are other good answers too, by the way.)

Having said all that, I did have a few issues with the article. There are some minor inaccuracies in the code extracts, though I dare say that can easily be fixed. The advice to use Model MBeans rather than Standard MBeans, because of inheritance problems with the latter, seems to ignore the class I find that most cases where you might want to use Dynamic MBeans (of which Model MBeans are a kind) can more simply be coded using this class or a custom subclass.

The advice about ignoring thread safety is somewhat dangerous. While it is true that concurrent updates to statistics are typically rare, the Java Memory Model basically allows a thread to hold on to its private copy of a field for as long as it likes provided there's no synchronization. So with an aggressively-optimizing system you could find that each thread was maintaining its own copy of a supposedly-common set of statistics. The values you would observe would be essentially random. If you don't want to pay the penalty of synchronizing across a read-modify-write (like counter++ or whatever), but you also don't want to run the risk of the random behaviour I just mentioned, then declaring fields volatile is a good compromise. This can still give wrong results in the face of two concurrent read-modify-writes but as Ron says this is likely to be too rare to make any significant difference to the statistics.

Anyway, Ron finishes this Part 1 with this striking screenshot where the humble JConsole is used to present some very useful information. I'll be looking forward to Part 2!

JConsole screenshot showing Glassbox instrumentation