You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@activemq.apache.org by "Christopher L. Shannon (JIRA)" <ji...@apache.org> on 2015/08/07 15:04:45 UTC

[jira] [Updated] (AMQ-5915) Support a Java API for the RuntimeConfigurationPlugin

     [ https://issues.apache.org/jira/browse/AMQ-5915?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Christopher L. Shannon updated AMQ-5915:
----------------------------------------
    Description: 
Currently the RuntimeConfigurationPlugin supports modifying some parts of the broker at runtime by changing the xml configuration so the broker doesn't need to be restarted to pick up the changes.

However, there are 2 issues with this approach.  First, in my situation I do not always use xml to configure the broker.  Many times a broker will be configured using Java (configuring a BrokerService directly) and I will store the configuration in a different way to manage this.  Second, I don't always want to permanently change the configuration.  Sometimes I need to temporarily create a new virtual destination for dynamic data flows but don't necessarily need to persist it in between restarts.

Because of this, it would be useful in some cases to be able to make changes to the broker configuration using a Java API to programmatically do things such as modifying the virtual destinations.

These changes would be temporary in nature as they wouldn't be persisted as they would be if xml was used.  However, if these changes need to be persisted the user could simply use xml to configure the broker or be responsible for storing this information however they want to recover after a restart of the broker.

  was:
Currently virtual destinations must be added before the broker is started by adding them to a virtual destination interceptor.  This is because of how the virtual destinations are processed on broker start up.

I need to be able to add and remove virtual destinations dynamically after the broker is already running to support dynamic dataflows.  For example, sometimes I need to temporarily forward messages from one destination to another (such as a topic to queue) without having to restart the entire broker and change the configuration.

    Component/s: Broker
        Summary: Support a Java API for the RuntimeConfigurationPlugin  (was: Support dynamically adding Virtual Destinations)

> Support a Java API for the RuntimeConfigurationPlugin
> -----------------------------------------------------
>
>                 Key: AMQ-5915
>                 URL: https://issues.apache.org/jira/browse/AMQ-5915
>             Project: ActiveMQ
>          Issue Type: New Feature
>          Components: Broker
>            Reporter: Christopher L. Shannon
>            Assignee: Christopher L. Shannon
>             Fix For: 5.13.0
>
>
> Currently the RuntimeConfigurationPlugin supports modifying some parts of the broker at runtime by changing the xml configuration so the broker doesn't need to be restarted to pick up the changes.
> However, there are 2 issues with this approach.  First, in my situation I do not always use xml to configure the broker.  Many times a broker will be configured using Java (configuring a BrokerService directly) and I will store the configuration in a different way to manage this.  Second, I don't always want to permanently change the configuration.  Sometimes I need to temporarily create a new virtual destination for dynamic data flows but don't necessarily need to persist it in between restarts.
> Because of this, it would be useful in some cases to be able to make changes to the broker configuration using a Java API to programmatically do things such as modifying the virtual destinations.
> These changes would be temporary in nature as they wouldn't be persisted as they would be if xml was used.  However, if these changes need to be persisted the user could simply use xml to configure the broker or be responsible for storing this information however they want to recover after a restart of the broker.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)