> Thanks Amy ! > > That was my initial understanding. > > The problem is that the ModelMBean implementation in JMX-RI and MX4J > don't seem to behave this way, and the spec wording is ( page 84 in the > 1.1 PDF ):
I believe ModelMBean implementation in JMX-RI and MX4J behave this way for all external Notification listeners. > > "In the model MBean, AttributeChangeNotifications are sent to a separate > set of listeners than those that other notifications would go to. All other > notifications should go to listeners who registered using the methods > defined in the NotificationBroadcaster interface. > AttributeChangeNotifications can also be sent to all notification listeners > simply by using the NotificationBroadcaster interface alone." > > Since we are using model mbeans, ACN are sent to the "separate set", > and "all other" notifications go to listeners registered using > NotificationBrodacaster. That's the current behavior for JMX-RI, MX4J and > modeler. I believe this is only true for AttributeChangeNotifications generated by the internal mechanism that is enabled when a listener internal to the ModelMBean is added with addAttributeChangeNotificationListener(). I think this was intended to allow implementing persistance on a per ModelMBean basis and was not intended to deliver generic AttributeChangeNotifications. > > Is there any clarification of the spec - or another part that I overlooked? > > I understand that this particular restriction is only on model mbeans - > and it would be possible for regular mbeans to send attribute changes > to all listeners. So a possible solution would be to modify modeler > and make it a "dynamic mbean" ( or keep it model mbean but not implement > this separation ). > > Costin > > > > Amy Roh wrote: > > > Costin, > > > > Costin Manolache wrote: > >> Craig, Amy - or anyone who knows JMX, I need help :-) > >> > >> I just can't find any way to add an attribute change listener > >> in the whole JMX spec, unless I have the instance of the model > >> mbean. And there is no way to get that instance. > >> > > > > I talked to Hans Hrasna in JMX team and I got the following answers. > > > > It IS possible to manage all attribute changes via JMX and persist them > > using attribute change listener using the current spec. > > > > It's up to the MBean owning the attribute of interest to create and send > > attribute change notifications when the attribute change occurs. So the > > NotificationBroadcaster interface has to be implemented by any MBean for > > which an attribute change is of interest. > > > > Example: If an MBean called myMbean needs to notify registered listeners > > when its attribute: > > > > String myString > > > > is modified, myMbean creates and emits the following notification: > > > > new AttributeChangeNotification(myMbean, sequenceNumber, timeStamp, > > msg, "myString", "String", oldValue, newValue); > > > > > > One just adds a NotificationListener. AttributeChangeNotification is > > emitted just like any other notification. > > > > > >> All query and get methods in MBeanServer return ObjectInstance - > >> i.e. name and class, but no 'instance'. > >> > >> There is an 'addNotificationListener' that takes the object name - > >> but the spec ( and implementation ) doesn't allow this to register > >> attribute change listeners, and att changes are not sent to > >> listeners registered with this method ( there is an "all other but > >> attribute changes" in the PDF file ). > > > > > > NotificationListeners registered on an MBean will receive the > > AttributeChangeNotifications just like any other notification. There is > > no such special type "attribute change listeners". > > > > Hope this helps. > > Amy > > > >> > >> I'm stuck. I can add some code to the modeler mbean to work > >> around, but the solution won't work for other mbeans. > >> > >> What I want to do is find all attribute changes done via JMX and persist > >> them - if you remember my old proposal. At the moment I'm not very sure > >> it can be implemented. The only possible solution to revive it would be > >> to force all attribute changes to go through a modeler-specific interface > >> or to require the use of the modeler for all mbeans. > >> > >> Costin > >> > >> > >> > >> -- > >> To unsubscribe, e-mail: > >> <mailto:[EMAIL PROTECTED]> For additional > >> commands, e-mail: <mailto:[EMAIL PROTECTED]> > >> > > > > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
