[
https://issues.apache.org/jira/browse/LOG4J2-1841?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15906586#comment-15906586
]
Matt Sicker commented on LOG4J2-1841:
-------------------------------------
Can you give more details on how you're deploying everything? Such as versions.
If you're using Jetty 8 at least (which is EOL), you'll have Servlet 3.0 which
means that everything should work correctly. The issue in LOG4J2-248 only
affects Jetty 6 and 7 [which are pretty
old|https://wiki.eclipse.org/Jetty/Starting/Jetty_Version_Comparison_Table].
However, this is an interesting issue determining the correct ClassLoader since
it's not being used to load classes but to find the proper
LoggerContext/configuration file. This is a very peculiar circumstance, and I
think I need more details on your use case to determine the root cause.
> 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
