We are beginning a major piece of work to change the configuration and management mechanism that underlies the Java Broker.
Why? It currently has a mixed model for storage of configuration: some configuration items are held in XML files, some are held in store, and some can be held in both. There is no clear model as to which source should prevail in the event of overlaps. Management abstraction is poor (it is interposed into the broker core) making the introduction of new management interfaces problematic. What? We are intending to throughly overhaul of whole configuration/management mechanism. We are considering major changes in the following areas: 1) New configuration model with backed by consistent storage model 2) Removal of configuration XML 3) Management interfaces (embedded web interface, rationalised JMX interface, QMF) to allow the complete configuration the Broker from its out-of-the-box state (rather like the CPP Broker). The following wiki page documents the current ideas. This page will envolve over the next few weeks as the ideas crystalise. https://cwiki.apache.org/confluence/display/qpid/Java+Broker+Unified+Configuration Any contributions/questions would be welcome but please reply on list rather than commenting on page. cheers, Keith. --------------------------------------------------------------------- Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:[email protected]
