[ https://issues.apache.org/jira/browse/ACTIVEMQ6-82?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14333493#comment-14333493 ]
Justin Bertram commented on ACTIVEMQ6-82: ----------------------------------------- [~scoopex], I think maybe you are commenting under the impression that this issue was filed against ActiveMQ 5.x. However, it is filed against ActiveMQ 6 so I don't think your comment (or link) is germane to this issue. > 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)