[
https://issues.apache.org/jira/browse/ACTIVEMQ6-82?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14333476#comment-14333476
]
Marc Schöchlin commented on ACTIVEMQ6-82:
-----------------------------------------
That's not true. You can define alternative settings in /etc/default/activemq,
~/.activemqrc.
Due to a broken merge "./activemq setup <the-desired-defaults-file>" the
created file was a bit chaotic but usable.
If you invoke the "activemq" script without parameters, you should get suitable
help output.
Release 5.11.0 provides a improved init script - see AMQ-5378.
>From my point of view this bug is obsolete.
> start script limitations
> ------------------------
>
> Key: ACTIVEMQ6-82
> URL: https://issues.apache.org/jira/browse/ACTIVEMQ6-82
> Project: Apache ActiveMQ 6
> Issue Type: Bug
> Environment: UNIX
> Reporter: Daniel Pocock
>
> This issue concerns the start script:
> ./distribution/activemq/src/main/resources/bin/activemq
> There are various issues with JAVA_ARGS at the bottom:
> a) memory parameters are hard-coded in the script and can't be overridden
> without modifying the script
> b) data.dir is hardcoded in the script and can't be overridden without
> modifying the script
> Problem (a) was also present in HornetQ while problem (b) was not there.
> With HornetQ 2.3, it was possible to override the data.dir and also add other
> properties or JMXetric to the JVM command line by setting the CLUSTER_PROPS
> variable in a local wrapper script. However, setting heap parameters in
> CLUSTER_PROPS was ineffective because the HornetQ run.sh would then set them
> to other values later on the command line.
> JBoss / Wildfly seems to do a better job of splitting the logic and
> configuration, they have a script called bin/standalone.sh that contains the
> logic and a separate file, bin/standalone.conf that can be customized with
> environment variables. I think this would be a good model for ActiveMQ 6 to
> follow. Is there already any discussion about refactoring the script?
> This is important for various reasons:
> - people deploying the broker in production environments don't like to modify
> the scripts supplied by a vendor, they usually prefer to have a configuration
> file of their own
> - when upgrading, it is an extra hassle to merge changes into the scripts if
> they have been modified locally
> - some people may want to run multiple instances using the same installation
> directory, same scripts and just using different data and log directories
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
