Page History

...

The below tables (generated from the attached spreadsheet) map out the base attributes and statistics each object type will have:

Overall work plan

1. Update BDB+Derby message stores to use new configuration storage model, representing ConfiguredObjects in a more generic fashion through storage attributes as JSON rather than specific table columns as at present.
   • Maintain existing store interface for now, use a new layer shared between BDB+Derby to convert existing objects into the JSON format stored by the new store schema, allowing later change of the store interface using the same on-disk format.
   • Update message content and metadata references to queues to use ids rather than names (allowing queues to be renamed).
   • TODO: what about messages for queues that are definied in XML? (Possibly generate UUID based from name (nameUUIDFromBytes(byte[] )
2. Refine store upgrade process using a model whereby the broker automatically performs the upgrades between each store version upon startup (inc multiple upgrades spanning version gaps).
   • Isolate individual upgrade steps, remove version numbers form the tables and have a version table etc (See Robs patch for example)
   • Convert existing messages to use new id-reference to their associated queue.
3. Complete implementation of new plugin based JMX MBean adaption layer.
   • VirtualHost, Exchange, Queue etc
   • Updating of tests as necesssary and/or creation of new unit tests to replace old system tests where possible.
   • UserManagement, LoggingManagement MBeans still TBC
4. Extract the Operational Logging from the core broker and define as a plugin listening for configuration events.
5. (Complete) Definition of the REST management interface
6. (Complete) Implementation of the REST management interface
7. Design the desired layout for the new web management UI
8. Get the basic web management ui running
9. Make the ui 'pretty'

...