[
https://issues.apache.org/jira/browse/ARTEMIS-2303?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16826120#comment-16826120
]
SL commented on ARTEMIS-2303:
-----------------------------
Hello,
Thank you for your response.
Yes, I used this workaround, which is a viable for some cases.
However, the system properties is some sort of a super global, and as such is
not a very clean way to feed the configuration if the jvm is not dedicated to
the broker.
* You have to pe picky about your properties names, to be certain no to cross
other environnements variables.
* If the want to run two brokers. For exemple in a unit test, or if the broker
is embedded in a web app and you deploy 2 or more copies of your webapp on the
same application server, you'll have to split the broker configuration to use a
different set of variables names for configuration, etc.
There are always workaround sfor thoses cases ; you can use docker images to be
sure to deploy separate applications servers, etc. But it put a lot of burden
on the external requirements and IMHO it goes against the idea of the embedded
broker, which is to be flexible about is integration patterns.
Best regards,
> Override properties in broker.xml with file or map
> --------------------------------------------------
>
> Key: ARTEMIS-2303
> URL: https://issues.apache.org/jira/browse/ARTEMIS-2303
> Project: ActiveMQ Artemis
> Issue Type: Wish
> Components: Broker
> Affects Versions: 2.7.0
> Reporter: SL
> Priority: Minor
>
> Currently, Artemis can use system properties to substitute values in
> broker.xml.
> It would be nice if there was a mean to fetch the properties from a file OR a
> {{Properties}} instance instead, for embedded brokers and unit tests.
> Actually, the properties are set via
> {code:java|title=ConfigurationImpl.java}
> @Override
> public Configuration parseSystemProperties() throws Exception {
> parseSystemProperties(System.getProperties());
> return this;
> }
> {code}
> which is called from {{parse(...)}} and {{internalStart()}} ; there should be
> a way to feed explicitly the properties from the upper layers.
> This is sort-of a regression from AMQ5 which inherited some flexibility from
> its spring configuration in those cases.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
