[
https://issues.apache.org/jira/browse/LOG4J2-1841?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15905285#comment-15905285
]
Matt Sicker commented on LOG4J2-1841:
-------------------------------------
The component properties file is a way to override system properties specific
to log4j-api and log4j-core (and other modules under org.apache.logging.log4j).
I'm actually not sure if in theory that would work here, but if you're
deploying log4j-api in each war, it should work.
> Problems with consequences after LOG4J2-248
> -------------------------------------------
>
> Key: LOG4J2-1841
> URL: https://issues.apache.org/jira/browse/LOG4J2-1841
> Project: Log4j 2
> Issue Type: Bug
> Components: Boot
> Affects Versions: 2.8
> Environment: Linux, Tomcat, WebApps
> Reporter: Seweryn Habdank-Wojewodzki
>
> Situation till Log4j v. 2.5 (including it):
> 1. One instance of embedded Jetty (programatically started) WITHOUT
> definition of the log4j.configurationFile variable.
> 2. WAR deployed on within this concrete instance of the embedded Jetty.
> 3. WAR internally contains own log4j2.xml file. So every Log4j instance,
> which is global for the WebApp, but local for the Jetty, will search and use
> configuration in own class path.
> Works in the way that every Web-App got own Log4j configuration and will
> operate according to own definitions (appenders, layouts, loggers).
> In the Log4j v. 2.6 and later in the same setup we are observing the
> following:
> Log4j in the applications are reporting problem that config file (log4j2.xml)
> is not visible. Thus we got message, that Log4j will switch to backup mode
> which will write only ERRORs in the console.
> We debuged that issue and found that change made in:
> https://issues.apache.org/jira/browse/LOG4J2-248
> seems to be the main reason.
> We cannot asses if this change was made only with respect to some PMD warning
> or it has as well some design considerations in background.
> The consequence is that Web Server instance shall define
> log4j.configurationFile variable, but also it means ALL WebApps within
> Application Container will use one single configuration, what makes
> definitely problem, as all WebApps providers must agree on ONE configuration
> including appenders configuration, message Layout and so on.
> Consider this report and provide solution (or workaround) or maybe just
> reasonable comment for the given system setup, please :-).
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
