On Wed, Apr 22, 2009 at 4:11 PM, Robbie Gemmell <robbie.gemm...@gmail.com> wrote:
> 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. I think we should exclude Desired Future Endstate from consideration for this work. The 0-10 stuff is obviously relevant, since it will be taking place concurrently. Having said that, I think that there's definitely some work that can be done to improve the current API. > 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... We're going to need to keep the existing API for a bit, if we're going to be breaking stuff I strongly feel we need to do it for everything at once (server config, client APIs etc). Creating a new one entirely might not be inappropriate, but we are going to have to coordinate it with qpid-cli amongst others. If we do decide to do this we're going to need to do some requirements gathering. > 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. This makes doing that a bit easier. It's not something we want to do lightly but it might be helpful. :) One question we really want to solve is how to add functionality in a less intrusive manner. Once we reach a stable API we're going to still need to be able to extend it, and have plugins contribute their own management functionality easily and portably. - Aidan -- Apache Qpid - Give me convenience or give me death http://qpid.apache.org --------------------------------------------------------------------- Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
