Skip to main content

JMX API 2.0 Early Draft Review

Posted by emcmanus on December 28, 2007 at 2:14 AM PST

The href="">first
draft of JSR 255 is out! This defines version 2.0 of
the JMX API. We're planning to integrate it into the Java SE 7
platform, subject to the approval of the Expert Group for that

Here's a summary of the important changes. If you're
interested, I'd encourage you to download the draft and look at
the summary in the Overview Description, which has links into
the relevant parts of the API.

This draft contains all the major features that we are planning
to add in this version of the API. If there's anything you'd like
to see changed, this would be a very good time to href="">let us know!

Namespaces and Cascading

The concept of namespaces is new. All MBeans whose domain
begins with foo//, for example
foo//com.example:type=CacheController, belong
to the namespace foo//. Previously,
MBeanServer.queryNames(null, null)) returned
a list of all MBeans. Now, MBeans within namespaces do not
appear in that list. Additionally, namespaces can contain
Virtual MBeans which do not have to exist as Java
objects when they are not being accessed. Namespaces
allow much improved scalability, especially when accessing
certain MBeans is expensive.

Cascading or Federation means that it is
straightforward to import MBeans from a remote MBean Server as if they
were local. This href="">blog
entry gives an overview of what Cascading is about.

Event Service and Notifications

The Event Service provides greater control over notification
handling than the default technique using
MBeanServer.addNotificationListener. The Event
Service separates the logic for notification handling from the
particular connector that you are using. You can transport
notifications using that connector, or using a completely
different transport. See the description of the package for more

A new class QueryNotificationFilter
allows notifications to be filtered using the existing query

Resource injection provides an alternative to implementing the
NotificationBroadcaster interface or extending the
NotificationBroadcasterSupport class. See the next

Annotations and Resource Injection

MBeans can now be defined using annotations. Also, the
@Resource annotation allows an MBean to get a reference
to its MBeanServer and ObjectName references, as an alternative
to implementing MBeanRegistration.

blog entry provides details and rationale.

Client Contexts and Localization

MBeans now have access to a context that can contain
information such as locale or transaction ids. (Note though that there
is no explicit support for transactions in the API.)

The descriptions in an MBeanInfo can be
localized using a new method
MBeanInfo.localizeDescriptions. A way will be
provided to cause this method to be called for all MBeans, using
a locale communicated by a remote client. The details are still
being sorted out so this area of the API will change.


A new Query Language provides an alternative way to
specify queries that is often simpler than constructing
QueryExp objects using the static methods of the
Query class. (The idea of an SQL-like query
language for JMX queries was first proposed by Norbert Lataille
and Marc Fleury in 2000, although the language in this draft is
not derived from that proposal.)

Attributes appearing in a query can now use a dot (.) to
specify a value contained in an attribute of complex
, similar to the existing support in the package.


The type mappings can now be customized for any MXBean
using annotations or options. Previously the mapping rules were

Options for StandardMBean and Proxies

A new MBeanOptions
class provides control over details of StandardMBean
and MXBean proxy operation.


A new interface DynamicWrapperMBean gives
better behaviour for MBeans that wrap other objects, in
particular as regards class loading.

NotificationManager interface

Three methods of the MBeanServerConnection
interface are promoted to a new parent interface
NotificationManager, which can be implemented by
classes such as EventClient that provide

Model MBeans

It is no longer required that the Descriptor
in, for example, ModelMBeanAttributeInfo contain redundant
descriptorType and name fields. The
previously-required values are supplied
by default
if omitted. (Thanks to Lars Westergren for this

Send feedback!

Feel free to comment here, or send mail to href="">



Related Topics >>