I'd do A, but implement it in a shell script that wraps the standard
ActiveMQ one, so you don't have to figure out how to get your class loaded
before activemq.xml.

Or isn't this the type of thing Puppet is meant for?

Tim
On May 8, 2016 9:29 AM, "Raffi" <raffi.onj...@gmail.com> wrote:

> Looking for advice on how to update activemq.xml in a distributed topology
> that uses M/S pairs and NoB.
>
> Some ideas we're considering...
>
> Option A: *Custom Startup Bean*
> On startup (before activemq.xml is read), a custom class queries GIT/SVN
> for
> latest version of broker config files, comparing version to those deployed
> locally, pulls files from GIT overwriting local ones. After which broker
> reads config and starts up normally.
> Broker reloading would be triggered over JMX.
>
> Option B: *Jenkins Pipeline*
> A workflow that pushes config files to brokers sequentially, using JMX to
> trigger broker reload to pick up config changes.
>
> Option A is cleaner and simpler; Jenkins pipeline could get messy
> identifying and/or recovering from startup failures.
>
>
>
>
>
> --
> View this message in context:
> http://activemq.2283324.n4.nabble.com/How-to-update-activemq-xml-config-in-distributed-topology-tp4711732.html
> Sent from the ActiveMQ - User mailing list archive at Nabble.com.
>

Reply via email to