logging-log4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Seweryn Habdank-Wojewodzki (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (LOG4J2-1841) Problems with consequences after LOG4J2-248
Date Fri, 10 Mar 2017 07:29:04 GMT

    [ https://issues.apache.org/jira/browse/LOG4J2-1841?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15904613#comment-15904613
] 

Seweryn Habdank-Wojewodzki commented on LOG4J2-1841:
----------------------------------------------------

Thanks a lot for very fast response. I really appreciate it.

Before you will roll it back, please try to reproduce it or discuss with others.
We did not tested this behaviour in all possible Application Containers.
Perhaps every container bahaves differently and that is tricky part :-).

@Matt: Do you mean that local variable definition will be used and 
configuration loader will got proper log4j2.xml?
I will talk about this  workaround with others :-).

> 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 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-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org


Mime
View raw message