Thank you everyone that responded.
For now I’ve recommended an EnvironmentFile that populates JAVA_ARGS_APPEND.
I’m going to look at what can be done with properties because that sounds
interesting and in line with the way we deploy our in house software. From the
documentation it isn’t clear if I could embed custom properties for use in
broker.xml and I haven’t tested it yet.
e.g. we use each of the following:
```
<broker-connections>
<amqp-connection uri="${raveMirrorConnectionStr}"
name="${raveMirrorName}" user="${raveMirrorUser}"
password="${raveMirrorPassword}">
<mirror/>
</amqp-connection>
</broker-connections>
```
```
<xi:include href="${raveConfigDir}/addresses.xml"/>
```
From: Clebert Suconic <clebert.suco...@gmail.com>
Date: Friday, November 18, 2022 at 12:26 PM
To: users@activemq.apache.org <users@activemq.apache.org>
Subject: Re: Recommended way to define instance properties
@Stephen I would like to also point you to broker-properties.
you can start a broker with :
./artemis run --properties <properties-file>
Where BeanUtils can be used through the properties file to customize
anything on top of broker.xml
Some users have been using that to have a single broker.xml on all
their instances and have the properties to be unique on each instance.
It's also being used by the https://artemiscloud.io operator
On Fri, Nov 18, 2022 at 11:14 AM Robbie Gemmell
<robbie.gemm...@gmail.com> wrote:
>
> 2.27.0 included the addition of JAVA_ARGS_APPEND for the command run
> by the startup script. You should be able to use that env variable
> more simply to make additions to the startup args, e.g inline before
> calling the script, since it isnt used for anything else unlike the
> JAVA_ARGS one.
>
> On Fri, 18 Nov 2022 at 15:55, Clebert Suconic <clebert.suco...@gmail.com>
> wrote:
> >
> > You should either keep doing these changes manually after the upgrade,
> >
> >
> > or keep these variables in a calling script.
> >
> >
> >
> > if you can think of a better way to do this? perhaps a new properties
> > files for custom modifications? but if you keep these variables in a
> > caller's that's pretty much all the same.
> >
> >
> > On Fri, Nov 18, 2022 at 10:28 AM Stephen Baker
> > <stephen.ba...@rmssoftwareinc.com> wrote:
> > >
> > > My organization had been using artemis.profile to define additional
> > > instance parameters eg:
> > >
> > > RAVE_MIRROR_CONNECTION_STR=tcp://artms1.atl.raveu.net:5672
> > > RAVE_MIRROR_NAME=ATL
> > > RAVE_MIRROR_USER=rave
> > > RAVE_MIRROR_PASSWORD=password
> > > RAVE_CONFIG_DIR=/rave/artemis/deploy/example
> > >
> > > # Rave environment settings
> > > JAVA_ARGS="$JAVA_ARGS
> > > -DraveMirrorConnectionStr=${RAVE_MIRROR_CONNECTION_STR}
> > > -DraveMirrorName=${RAVE_MIRROR_NAME} -DraveMirrorUser=${RAVE_MIRROR_USER}
> > > -DraveMirrorPassword=${RAVE_MIRROR_PASSWORD}
> > > -DraveConfigDir=${RAVE_CONFIG_DIR}"
> > >
> > > However the new upgrade tool removes all of these lines leading to a more
> > > complex upgrade process. What is the recommended way going forward of
> > > providing parameters for use in broker.xml for the least friction with
> > > future upgrades?
> >
> >
> >
> > --
> > Clebert Suconic
--
Clebert Suconic
[EXTERNAL]: This email originated from outside of Rave Mobile Safety. Do not
click links or open attachments unless you recognize the sender and know the
content is safe.
