The 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 platform.
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 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
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 MBeanswhich 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 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
javax.management.event package for more information.
A new class
QueryNotificationFilter allows notifications to be filtered using the existing query subsystem.
Resource injection provides an alternative to implementing the
NotificationBroadcaster interface or extending the
NotificationBroadcasterSupport class. See the next section.
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
This 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 belocalized 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 type, similar to the existing support in the
The type mappings can now be customized for any MXBean using annotations or options. Previously the mapping rules were fixed.
Options for StandardMBean and Proxies
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.
Three methods of the
MBeanServerConnectioninterface are promoted to a new parent interface
NotificationManager, which can be implemented by classes such as
EventClient that provide addNotificationListener/removeNotificationListener functionality.
It is no longer required that the
Descriptor in, for example, ModelMBeanAttributeInfo contain redundant
name fields. The previously-required values are supplied by default if omitted. (Thanks to Lars Westergren for this contribution.)
Feel free to comment here, or send mail to firstname.lastname@example.org.