Skip to content
Create and register mbeans and hierarchy through MVC model using MBeanInterceptor
Java
Branch: master
Clone or download
Fetching latest commit…
Cannot retrieve the latest commit at this time.
Permalink
Type Name Latest commit message Commit time
Failed to load latest commit information.
docs
examples
gradle
src/main/java/com/tersesystems/jmxmvc
.gitignore
.travis.yml
LICENSE
README.md
akka.png
build.gradle
gradle.properties
gradlew
gradlew.bat
settings.gradle
version.properties

README.md

jmxmvc

Bintray Latest version License Apache2

Travis CI

This is an MVC breakout of MBeanInterceptor. This lets you create a model and automatically display object names and hierarchy inside an MBeanServer -- the tree bit on the left that displays all the MBeans -- without having to do the work of registering beans individually.

It is based on the OpenDMK examples from Sun Microsystems available at https://github.com/wsargent/jmx-interceptor.

Examples

There are two examples, one which displays Akka Actors in JMX according to the model, and another one which displays the alphabet.

For example, if you open up the Akka example with ./gradlew run and then use the createChild operation a few times, you get this:

akka.png

Why use virtual mbeans?

JMX is built around the concept of MBeans and an MBeanServer. All of the methods involving JMX (Standard MBeans, MXBeans, Dynamic MBeans, Open MBeans, Model MBeans) have the common end point of registering an object instance directly against an MBeanServer:

import javax.management.*;

class RegisterMBean {
    public ObjectInstance register(Object mbean, ObjectName objectName) throws Exception {
       MBeanServer mBeanServer = ManagementFactory.getPlatformMBeanServer();
       return mBeanServer.registerMBean(mbean, objectName);
    }
}

A reference to the instance is always stored by the mbean server. This means that when you make an object available through JMX, there are knock-on effects. It takes up memory. It exists in a flat namespace that is searched by the default install. If you want to expose a large number of objects through JMX, you'll run into runtime overhead.

Using an interceptor takes care of all of this. Per the OpenDMK documentation:

"The interceptor handles operations on MBeans it owns itself, and forwards others to the default interceptor. An interceptor might own all MBeans whose names match a particular pattern, for instance. In this way, MBeans do not necessarily have to be Java objects. This is very useful when there are a great many managed objects, or when they are very volatile."

So the key idea here is that there is no persistent MBean object registered. Instead, a short-lived dynamic mbean is created and returned for every query.

You can’t perform that action at this time.