1 2 3 4 Previous Next 47 Replies Latest reply on Mar 29, 2010 12:45 AM by Clebert Suconic

    Configuration storage

    Clebert Suconic Master

      So far the requirements I got is we should be able  to persist configuration for :


      - Connection Factories

      - JMS Queues

      - JMS Topics

      - Address Settings

      - Security Settings


      I think we could also optionally include:

      - Diverts

      - Bridges



      Instead of doing a JMS Journal, I'm considering implementing what I call a ConfigurationManager, that will persist any kind of configuration you want.



      Each config item we have would be represented by ConfigurationItem, with these attributes:



         private final SimpleString type;
         private final SimpleString key;
         /** The id for the configuration item on the journal */
         private volatile long journalID;
          * This represents the config before parsing and storing
          * It will be empty after parsed or stored.
         private byte[] data;
         /** this presents the config after being parsed */
         private Object configValue;



      The ConfigurationManager would look like this interface:


      public interface ConfigurationManager
           void storeItem(ConfigItem item);
           void deleteItem(SimpleString type, SimpleString key);
           void deleteItem(ConfigItem item);
           ConfigItem[] recoverItems();
           ConfigItem[] recoverItems(SimpleString type);



      For example, JMSManager would store the configs as new items are stored.


      Same deal with hornetQServer. it would store configs as new security settings are stored.


      On load time, JMSManager would be able to recoverItems by type, and the JMSManager would be able to recreate the queues and JMS connection factories.


      with this we could keep any configuration persisted.. and it would be about the same ammount of time to develop as a plain JMS Storage manager.

        1 2 3 4 Previous Next