I wasn't aware of this inconcistency. Do you know if its being fixed as part of the maintenance release?
> Solution 1.
> Change JBossMX to agree with the RI/javadocs not the
hrmm... I don't trust the RI/javadocs to do the right thing all that much... in fact it seems they just mess up in a lot of places. So I'd prefer to go by the spec instead -- except in this case even the spec is inconsistent.
> Solution 2
> Compile a second copy of the compliance/performance
> over jmxri.jar to avoid the "static final"
> at compile time.
You might also try to post on JMX-INTEREST to find out what the real value should be, if you feel up to it.
> PS. I fixed the registry problems you spotted.
> Interestingly, the Relation Service's notifications
> send a RelationService object as the source.
> I already coded JBossMX to ignore this and used the
> object name.
its actually not just a registry specific problem... in general all listeners that are registered through MBean server should have their notification source fields set as the MBean's object name, where as the broadcasting MBean itself should be allowed to set the source as a reference to itself (this).
The RI handles this by intercepting all addNotificationListener calls and registering its own listener to whichever target the original invocation was meant for. When the MBean sends a notification, the server then receives it, replaces the 'this' reference with the corresponding object name and resends the notification to the original listener. That functionality is currently missing from our server.
Straight from the horses mouth
>From: Eamonn McManus
>Subject: Re: [JMX-FORUM] MBean Server Notifications
>Date: Thu, 14 Mar 2002 16:44:07 +0100
>We have already identified this as an issue for JMX 1.2. The
>choice is indeed the one from the javadoc and the RI, namely
>"JMX.mbean.[un]registered", even though this is inconsistent with
>form of other notifications. (Of course users only ever access it
>through the symbolic constants so they don't care much about that.
>Users who copied the strings shown in the PDF will have discovered
>that they don't work.) Existing code based on the RI will already
>have these values and we don't want to break that. Even existing
>that accessed these strings through the symbolic constants will have
>had the strings inlined during compilation, so changing them would
>break binary compatibility.
>Éamonn McManus, Sun JMX team
>For information on the Java Management extensions (JMX), please
>our home page at http://java.sun.com/products/JavaManagement/
>The JMX-FORUM archives are accessible at
good, will you make sure we're using the correct notification type string? (if we aren't already)