Re: Wrapping notification listeners?

Jeremy,

This is a somewhat tricky area of the JMX spec.  The fundamental problem 
is that the spec doesn't say whether equality (.equals(Object)) or 
identity (==) is used when you call removeNotificationListener, either 
on the MBeanServer or on a NotificationBroadcaster MBean.  The Reference 
Implementation uses identity, while MX4J uses equality.  This is 
potentially a source of portability problems, though in practice if you 
implement NotificationBroadcaster using inheritance from or delegation 
to NotificationBroadcasterSupport, and if your MBeanServer is from the 
same implementation, you should be OK.

If you implement NotificationBroadcaster yourself from scratch, then you 
are in trouble because you have to decide whether to use identity or 
equality.  If we change the spec to say explicitly that it is identity, 
then we break code that used MX4J and depended on the equality semantics 
of its NotificationBroadcasterSupport (but this code was already broken 
if you ran it on JDK 5.0 which includes the RI).  If we change the spec 
to say explicitly that it is equality, then we potentially break code 
that used the RI (including JDK 5.0) and dependend on identity.  It's 
true that you probably don't often have two listeners on the same MBean 
that are equal but not identical and want to be able to remove just one 
of them.

This is a problem for the next version of the spec (2.0, being defined 
by JSR 255).  My initial inclination is not to touch the spec since it 
is not obvious how it can be improved.

Concerning the specific behaviour of MX4J that you mention, if MX4J 
could supply an identical listener to removeNotificationListener to what 
it previously gave to addNotificationListener, that would certainly 
improve portability, in that it would allow a NotificationBroadcaster 
implementation that uses identity to work in the usual case.

Regards,
Éamonn McManus   JMX Spec Lead   +33 476 188 352


Jeremy Boynes wrote:
> The JavaDoc for MBeanServer.addNotificationListener() says that if the 
> source of a Notification is a reference to the MBean object the 
> MBeanServer will replace it with the MBean's ObjectName. This implies 
> that the MBeanServer needs to intercept the sending of the notification 
> to do this, which MX4J does by wrapping the supplied 
> NotificationListener in a 
> NotificationListenerMBeanServerInterceptor.ListenerWrapper
> 
> This means that the listener object passed to the mbean is not the same 
> (as in  == is false) as the one supplied. I cannot see anything in the 
> spec that describes such behaviour so presumably this is permissible.
> 
> However, we also wrap the listener when removing it. As a result, the 
> object passed to the mbean on remove not only != the original but also 
> != the wrapped value supplied during the add. The wrapper does delegate 
> equals() and hashCode() to the original instance, so to anything using 
> the Collections interfaces (like MX4J's impl of 
> NotificationBroadcasterSupport) they will appear the same but if the 
> MBean relies on object identity they will appear different.
> 
> I can't find anything in the spec that defines how identity behaves here 
> - specifically, I don't see a requirement that the identity has to be 
> the same between add() and remove(). Am I missing something?
> 
> Thanks
> -- 
> Jeremy


-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl