JDK-6319823 : new mbean register/unregister notification for groups of mbeans
  • Type: Enhancement
  • Component: core-svc
  • Sub-Component: javax.management
  • Affected Version: 1.2.1
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2005-09-05
  • Updated: 2011-03-08
  • Resolved: 2011-03-08
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 7
7 b43Fixed
Related Reports
Relates :  
JDK-4718350 - RFE: Wildcard support in notification filter
Relates :  
JDK-5108739 - Support virtual MBeans
Relates :  
JDK-4718351 - RFE: Listen to a set of MBeans in a single operation
Description
in order to scale things like cascades of mbeans and virtual mbeans (more generally,
anything using an interceptor to fake the existence of groups of mbeans) it would
be valuable to have the next JMX spec detail that a different notification may be sent
than that of 

MBeanServerNotification.REGISTRATION_NOTIFICATION | UNREGISTRATION_NOTIFICATION

in particular, a notification of the same form but containing an ObjectName pattern instead of an ObjectName would appear to be the most appropriate. This could be spec'd as the instance info for any mbean with this pattern can be considered to need refreshing (via a query with the same pattern).
Comments
EVALUATION Having MBeanServerDelegate emit notifications it didn't emit before is a problem. For example, careless users that wrote listeners like this... public class RegisterListener implements NotificationListener { public void handleNotification(Notification n) { if (n instanceof MBeanServerNotification) { if (n.getType().equals(MBeanServerNotification.REGISTRATION_NOTIFICATION)) ...handle register... else ...handle unregister... } } } ...will get a nasty surprise because the new notifications will be handled by the else clause. Of course ideally everybody will have explicitly checked the two types, but I wouldn't like to bet that everybody has. Instead, we will still standardize the new JMX.mbean.[un]registered.group types, but it is the *namespace* MBean (foo//:type=JMXNamespace) that can emit them. We won't provide anything by default that actually does this, but users can subclass JMXNamespace or JMXRemoteNamespace to do it. Similarly for JMXDomain (foo:type=JMXDomain). So in summary we are establishing a convention that is documented in the javadoc, but we are not adding anything to the code that uses that convention, whether as producer or consumer.
04-12-2008
EVALUATION Another possibility is to degrade the (un)registration semantics for Virtual MBeans, i.e. to allow them not to send a notification when an instance is created or destroyed, or perhaps only to send a notification if someone has explicitly registered an interest in that type of Virtual MBean. This does pose obvious compatibility problems with existing clients.
05-09-2005
EVALUATION This is certainly a problem that should be addressed. If support for Virtual MBeans is added to the JMX API (see 5108739) then when a new Virtual MBean handler is started, conceptually it must declare all the MBeans it handles. Today that means that it should strictly speaking emit one MBeanServerNotification.REGISTRATION_NOTIFICATION for every virtual instance it handles. Furthermore it should track the creation and deletion of its virtual instances and emit a notification each time. Having to do this somewhat negates the benefits of Virtual MBeans. The proposed change would be to have a notification that covers a range of ObjectNames and that could say that the set of MBeans with a name in this range has changed, without saying exactly in what way. The notification could possibly also say whether the set has gained or lost members. This notification could come from the MBeanServerDelegate, like the existing MBeanServerNotification. It could either be an MBeanServerNotification with a new type string, or another Notification subclass. The former solution may be better in that it is less likely to break existing (poor) code that casts a Notification from the MBeanServerDelegate into an MBeanServerNotification. ###@###.### suggests that for compatibility with existing clients, if there is a listener on the MBeanServerDelegate and we are unable to determine whether that listener expects the new notification type, we could trigger compatibility code that would issue a queryNames to discover the exact details of the change and issue as many old-style MBeanServerNotifications as necessary to reflect it. However, this does require the compatibility code to keep track of all the ObjectNames in every set of Virtual MBeans. One way that a listener on the MBeanServerDelegate could indicate that it does know how to deal with the new notification type would be by adding a NotificationFilterSupport that lists the type in its enabled types.
05-09-2005