[
https://issues.apache.org/jira/browse/LOG4J2-1841?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Seweryn Habdank-Wojewodzki updated LOG4J2-1841:
-----------------------------------------------
Description:
Situation till Log4j v. 2.5 (including it):
1. One instance of Tomcat WITHOUT definition of the log4j.configurationFile
variable.
2. Several WARs deployed on within this concrete instance of the Tomcat.
3. Every WAR internally contains own log4j2.xml file. So every Log4j instance,
which is global for the WebApp, but local for the Tomcat, 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 Tomcat instance shall define log4j.configurationFile
variable, but also it means ALL WebApps 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) for the given system
setup, please :-).
was:
Situation till Log4j v. 2.5 (including it):
1. One instance of Tomcat WITHOUT definition of the log4j.configurationFile
variable.
2. Several WARs deployed on within this concrete instance of the Tomcat.
3. Every WAR internally contains own log4j2.xml file. So every Log4j instance,
which is global for the WebApp, but local for the Tomcat, will search and use
configuration in own class path.
Works in the way that every Web-App got own Log4j config 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 Tomcat instance shall define log4j.configurationFile
variable, but also it means ALL WebApps will use one single configuration, what
makes definitely problem, as all WebApps providers must argee on ONE config
including appenders configuration, message Layout and so on.
Consider this report and provide solution (or workaround) for the given system
setup, please :-).
> 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 Tomcat WITHOUT definition of the log4j.configurationFile
> variable.
> 2. Several WARs deployed on within this concrete instance of the Tomcat.
> 3. Every WAR internally contains own log4j2.xml file. So every Log4j
> instance, which is global for the WebApp, but local for the Tomcat, 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 Tomcat instance shall define log4j.configurationFile
> variable, but also it means ALL WebApps 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) 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
