Skip navigation

The JMX Namespace feature has now been integratedinto the JDK 7 platform. You can read about it in detail in the online documentation for Here's my quick summary.

Namespaces add a hierarchical structure to the JMX naming scheme. The easiest way to think of this is as a directory hierarchy. Previously JMX MBeans had names likejava.lang:type=ThreadMXBean. Those names are still legal, but there can now also be names like othervm//java.lang:type=ThreadMXBean.

The othervm "directory" is a JMXNamespace. You create it by registering aJMXNamespace MBean with the special nameothervm//:type=JMXNamespace. You specify its contents via the sourceServer argument to theJMXNamespace constructor.

There are three typical use cases for namespaces. First, if you have more than one MBean Server in the same Java VM (for example, it is an app server, and you have one MBean Server per deployed app), then you can group them all together in a higher-level MBean Server. Second, if you have MBean Servers distributed across different Java VMs (maybe on different machines), then again you can group them together into a "master" MBean Server. Then clients can access the different MBean Servers without having to connect to each one directly. Finally, namespaces support "Virtual MBeans", which do not exist as Java objects except while they are being accessed.

There's much more to namespaces than I've described here. Daniel Fuchs is the engineer who did most of the design and implementation work on namespaces, and I expect he will have more to say about them in the near future on his blog.

[Tags: jmx jdk7 jsr255]

Shanliang Jiang talks about one of the main use cases of the Event Service from the new JMX API in this blog entry. You can use a wildcard ObjectName to subscribe to a set of MBeans. The Event Service tracks the arrival and departure of MBeans, so it will subscribe to new MBeans matching the pattern as they appear. The Event Service is already present in the latest draft of the JDK 7 API and you can try it out by downloading the latest snapshot.


[Tags: jmx jdk7 jsr255.]

Yesterday I cleaned up the umbrella bugthat lists the various things we are planning for version 2.0 of the JMX API, which is the version that should be included in Java SE 7. Here's a list of the things we were thinking of doing but are not now planning to.

In some of these cases, we realized after discussion in the Expert Group that the proposed feature was either not practical or too hard to nail down. For example, support for persistence would be good. But what would it look like? Would we give you some way to take a snapshot of every MBean? How would that snapshot be represented? How would it be restored? Or would we have a way for an MBean to define its own persistence explicitly? Then what could we usefully define that an MBean can't already do today?

In other cases, a reluctant engineering decision was taken because, though the feature would be useful, it would not be useful enough to justify the engineering work to specify it, implement it, and write spec conformance tests for it.

Here's the list, with explanations:

  • 4718350Wildcard support in notification filter

    This is superseded by the new class QueryNotificationFilter, which is more general.

  • 5108792 Add abstract base class to make coding DynamicMBeans easier

    Although this would occasionally be useful, the main thing it could do would be to implement getAttributes in terms ofgetAttribute and setAttributes in terms of setAttribute, and in practice people don't code Dynamic MBeans often enough for that to justify a new class.

  • 4718269 Model MBean should be extended to support EJB handles

    This one was never on the cards, because this API is part of the Java SE platform, and EJBs are part of Java EE.

  • 4718298ModelMBeanInfo.getConstructor(String) could be added

    ModelMBeanInfo is an interface so adding a method to it would be an incompatible change. (Existing classes that implement this interface would not have the new method.)

  • 6176837TabularDataSupport.entrySet() should prevent calls to Map.Entry.setValue on returned set elements

    I logged this one a few years ago for aesthetic reasons. The spec basically says "don't do this or things will break". A good spec should never say that. It should say "if you try to do this operation that would break things, you will get an exception". But in practice this is in a pretty obscure corner of the API and making it generate the exception would be a nontrivial amount of work, and probably imply a performance penalty, so the change was hard to justify.

  • 5031385 m-let file format should be XML

    Again MLet files are not a core part of the API so making this change would be hard to justify. What's more we'd probably have to work out how to support the previous almost-XML format and the new really-XML format at the same time, and that would be hard.

  • 6323896Support aggregation of multiple MBean Servers

    This is certainly something that we often see people needing, but the Expert Group discussion concluded that it would be very hard to define something that would be general enough to be useful while still simple enough to be understandable.

    I think this is still an interesting area for future work, but it will unfortunately not be part of the JMX 2.0 API.

    We will still support federation, meaning that you can group several MBean Servers into a single "master" MBean Server. But we will not support for example a predefined way to have an MBean in the master that shows the average of a certain attribute across each of the federated MBean Servers. (Users should still find it easy to address any given case by coding it explicitly.)

  • 6323795Metadata repository for JMX API

    The idea here is that you can see the metadata for every JMX MBean that currently exists (for example, its operations and attributes). But you can't see the metadata for every MBean thatmight exist. It would be great to be able to browse the MBean class hierarchy independently of instances.

    Although this is not planned for the 2.0 API, it would be an interesting project to use the new Namespace support to implement a namespace with one MBean instance for each class of MBean that exists (discovered perhaps by looking through the jars in the classpath). The MBeanInfo of each of these "template MBeans" would be the MBeanInfo that each instance of the corresponding class would have, or as near to that as we could deduce. (This idea is due to Nick Stephen.)

  • 5108724 Add support for persistence to JMX API

    I talked about this above.

  • 6323764 Add support for client sessions to JMX API

    The idea here was that a client could create an object on the server that represented some part of its state, for example a transaction or a set of notifications that the client is interested in or a long-running operation. However, the Expert Group considered that most of these cases could be addressed using "client contexts", a new feature where the client can communicate a context to the server with every operation. This context could be a locale or a transaction id or whatever.

None of these decisions is completely irreversible of course. But at this stage I think anyone with a very strong desire to see any of the departed features brought back would need to volunteer to do all the relevant engineering work!

[Tags: jmx jdk7 jsr255]

The new Event Service that is part of version 2.0 of the JMX API is available in the latest snapshot of the JDK 7 platform. The package description for the package summarizes what it is for and how to use it.

The description there starts like this:

This package defines the Event Service, which provides extended support for JMX notifications.

The Event Service provides greater control over notification handling than the default technique using MBeanServer.addNotificationListener or MBeanServerConnection.addNotificationListener.

Here are some reasons you may want to use the Event Service:

  • To receive notifications from a set of MBeans defined by an ObjectName pattern, such ascom.example.config:type=Cache,*.
  • When the notification-handling behavior of the connector you are using does not match your requirements. For example, with the standard RMI connector you can lose notifications if there are very many of them in the MBean Server you are connected to, even if you are only listening for a small proportion of them.
  • To change the threading behavior of notification dispatch.
  • To define a different transport for notifications, for example to arrange for them to be delivered through the Java Message Service (JMS). The Event Service comes with one alternative transport as standard, a "push-mode" RMI transport.
  • To handle notifications on behalf of MBeans (often virtual) in a namespace.

The Event Service is new in version 2.0 of the JMX API, which is the version introduced in version 7 of the Java SE platform. It is not usually possible to use the Event Service when connecting remotely to an MBean Server that is running an earlier version.

As with everything else in the new JMX API, we're always keen on hearing feedback, which you can add as a comment here or send to

The principal designer of the new Event Service is Shanliang Jiang, and he'll probably have some interesting things to say about it, which I'll link to from here.

[Tags: jmx jdk7.]