[
https://issues.apache.org/jira/browse/LOG4J2-1841?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15907505#comment-15907505
]
Matt Sicker commented on LOG4J2-1841:
-------------------------------------
So then is the servlet class loader not the correct loader here? That's what
would be used to find a classpath resource in your WEB-INF directory I thought
(sorry, haven't had to program in servlets in a while).
> 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: [email protected]
For additional commands, e-mail: [email protected]
