Hi all. Just kicking off some discussion on issues likely to affect what I do during the GSoC work, to help Aidan and I put together a better plan of action.
One upcoming elephant to consider is going to be AMQP 1.0 support and how its new messaging/component model will affect the management interfaces. As the Java broker is presumably going to support the current protocol versions and gain 1.0 (+ 0-10), this could/will somewhat muddy the management waters. Eg, Exchanges (sort of) going away, Links being added...VirtualHosts becoming merely part of the implementation details etc. This would presumably mean some methods being added, removed, or possibly moved to new/existing MBeans. Alternatively, an entirely new set of JMX interfaces could be exposed and coexist with the existing set to handle the new model and old models seperately, moving to just the new set at some future time. So many possible options... Another issue for discussion is versioning. In the previous work I did on the broker JMX capabilities, some issues cropped up with compatibility due to a required a change in the expected input (going from MD5-hashed password input to plain text to support a consistent user management interface) for some of the methods. Additional changes included altering of some attribute units for correctness and consistency, and introduction of some new attributes for FTD (since removed). These changes made it necessary and/or desirable to be able to distinguish the versions of each JMX MBean encountered, so a version property was added to the JMX ObjectName to do so. Depending on changes made to account for 1.0 management, it may be necessary or useful to rework this as well. Any thoughts out there? :) Robbie --------------------------------------------------------------------- Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
