Amy Roh wrote: >> 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.
Not sure we are talking about the same thing here. In MX4J, JMX-RI and modeler the model mbean will not send notifications about attribute changes to listeners registered via addNotificationListener(), and there is no way to register for attribute change notifications unless you have the instance of the model mbean ( which is not available ). The end result is that implementing config persistence using the attribute change notification won't work. Combined with the fact that there is no way to make distinction between 'external' attribute changes and 'internal' state change - my original proposal for config in 5.0 just won't work. Right now the only way I can see to improve the config in 5.0 is to have the admin ( or any UI/config mechanism ) use JNDI instead of JMX and operate on the passive data. I'm trying to find if the other way around works - i.e. use JNDI events to keep the 2 in sync - but it makes much more sense to use jndi rather than JNI for changing the configuration and persistence, and use JMX only to change the runtime config and monitoring ( there is a significant distinction between the 2 ). > 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(). The problem is there is no way to add attribute change notification listeners to a model mbean using the current API ( unless you have the instance ). > I think this was intended to allow implementing persistance on a per > ModelMBean basis and was not intended to deliver generic > AttributeChangeNotifications. That might work - i.e using modeler internals for persistence, or using internal APIs ( interceptors in MX4J ) for other mbeans. I'm still trying to find a simple solution - I'm very busy right now, but I'll send the results to the list as soon as I'm ready. IMO going the other way around has a number of important benefits and doesn't require many changes in the admin code ( the APIs are very similar, and most calls are concentrated in few utils ). In addition we can move most of the config and instrumentation code in the 'main' code ( since we already depend on JMX). Costin -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
