[
https://issues.apache.org/jira/browse/ARTEMIS-4785?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17850676#comment-17850676
]
Robbie Gemmell commented on ARTEMIS-4785:
-----------------------------------------
The etc dir is on the classpath to pick up various things other than the
logging config, the path to which was actually historically hard coded in the
script (before the SLF4J + Log4J switch). So I'm no sure you can just remove
etc from the classpath without significant change. Though renaming the file
wouldnt be needed if etc wasnt on the classpath except when running the broker.
As I mentioned the other day, even if the script did specify the file to be
used again then it wouldnt itself fix things; the script would also need to
specifically know whether you were using the run command or not, and behave
differently for it and the other commands, since they all load via the same
initial class and classpath stuff, and so would still all get the same logging
config even if were specified. Also, the 'shell' command can in turn run the
broker (and anything else that you might want logging for) currently, after the
initial load, so that would also need to do something different perhaps. Also,
the ability to replace the default config by supplying your own "-Dlog4j2..."
config for the broker as an override (it having the highest precedence) would
possibly become more complicated.
Your second comment notes 'we can do this for new instance creations'...but how
then are you handling upgrades with the upgrade command? It leaves a lot of the
config alone but it replaces the scripts with the current version, so in this
case the config would need to align to those updated scripts expectations, e.g
if you rename the log4j file and specify a -D config aimed a new instance
creation, the log4j file would probably need renamed during upgrade too...think
it possibly throws on not finding it if its explicitly specified. (You also
might not know what its normal name is if its already being specified as an
override, so do you write a new one if not finding it? Currently we only do
that if we find the old logging.properties file, when it gets switched out)
For me, I'd potentially be looking at moving the 'not-broker' commands to their
own separate tools script that can be configured appropriately, or just banning
the instance-level artemis command from running such 'not-broker' things, so
they cant interfere. Feels like perhaps its doing too many different things. Or
else changing things so they dont all use the same loader and classpath as
currently.
> log4j config from classpath and cli issue
> -----------------------------------------
>
> Key: ARTEMIS-4785
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4785
> Project: ActiveMQ Artemis
> Issue Type: Improvement
> Components: Configuration
> Affects Versions: 2.33.0
> Reporter: Gary Tully
> Priority: Major
>
> I have come across a strange issue where the root cause is the instance dir
> cli sharing the log4j config with the broker.
> the logging has a rolling file appender schedual of 1 minute. looks to be
> working fine, then use instance-dir/bin/artemis produicer --user invalid to
> generate logging... and the broker appender gets borked.
> The problem, the cli is reading the same log4j2 config from the etc dir on
> the classpath.
> This is not ideal.
> One workaroud is to use the installation dir artemis for producer!consumer
> commands.
> I wonder if we should use -Dlog4j.configuration to specify a file not on the
> classpath for the broker. and leave etc off the classpath?
> I guess there are a few ways to solve this. but there is indeed a gotcha here.
> thoughts?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org
For additional commands, e-mail: issues-h...@activemq.apache.org
For further information, visit: https://activemq.apache.org/contact
