Versions Compared

Old Version 12

changes.mady.by.user Robert Gemmell

Saved on

compared with

New Version Current

changes.mady.by.user Phil Harvey

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Migrated to Confluence 5.3

...

The following page is intended to document analysis and design aspects of efforts to unify the configuration model of the Java broker and provide it a single consistent storage model for configuration, held in a (durable) configuration store. The design for the new configuration store is in New design for the Java Broker configuration.

This is core to an overall effort to improve usability of the product and increase its suitability for use in Cloud environments. Components of this work include removal of the XML based configuration, addition of a new configuration model for broker entities, consistent storage of that model information, and new management functionality enabling a self-service style operation of remote broker instances via means such as browser based management and a REST API in addition to improved JMX support.



Table of contents

Table of Contents
maxLevel3

...

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

Excel
outputhtml
file^newConfigAttributesAndStatistics

...

.xls
showSheetNametrue
formatCelltrue

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'

...