Mailing-List: contact log4j-dev-help@logging.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Log4J Developers List" <log4j-dev@logging.apache.org>
Date: Thu, 25 Sep 2014 16:03:34 +0000 (UTC)
From: "Mike Calmus (JIRA)" <jira@apache.org>
To: log4j-dev@logging.apache.org
Message-ID: <JIRA.12736147.1408736975000.122272.1411661014244@Atlassian.JIRA>
In-Reply-To: <JIRA.12736147.1408736975000@Atlassian.JIRA>
References: <JIRA.12736147.1408736975000@Atlassian.JIRA>
 <JIRA.12736147.1408736975593@arcas>
Subject: [jira] [Commented] (LOG4J2-795) Problems when libraries are loaded
 as part of server startup classpath
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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

Mike Calmus commented on LOG4J2-795:
------------------------------------

So it turns out I missed some important variables in my testing. I tried again using log4j 2.0.2 with these results:

With commons-logging, log4j-api and log4j-core in the system classpath and with log4j-web either bundled with the application or in the system classpath things work fine.

Things stop working when log4j-jcl is added into the mix. With log4j-jcl in either the system classpath or bundled in the application no logging is generated.

Moving commons-logging from the system classpath into the application bundle made no difference. Even if it had, this configuration isn't possible in our environment because of issues with some apps that necessetate commons-logging and log4j 1.2 to be in the system classpath.

> Problems when libraries are loaded as part of server startup classpath
> ----------------------------------------------------------------------
>
>                 Key: LOG4J2-795
>                 URL: https://issues.apache.org/jira/browse/LOG4J2-795
>             Project: Log4j 2
>          Issue Type: Bug
>          Components: Core
>    Affects Versions: 2.0, 2.0.1, 2.0.2
>         Environment: Weblogic 10.3.6, Java 7
>            Reporter: Mike Calmus
>            Priority: Critical
>
> "works" means that there is logging. For some items there may be caveats.
> All tests were run using Weblogic 10.3.6 (a Servlet 2.5 container) running on Java 7. There were no difference when using Log4j 2.0 versus 2.0.1.
> When log4j libraries are loaded as a part of the server's startup classes (out current preferred configuration with Log4j 1.2.x):
> 1) Standard web-app configuration with configuration file specified in web.xml does not work
> 2) Configured with JndiContextSelector as the Log4jContextSelector system property it doesn't work when I have things configured correctly. If I exclude the JNDI lookup environment properties I get an error in the System log, but logging works.
> Removing the Log4j libraries from System startup and instead bundle them with the application (no other changes)
> Scenario 1 above now works.
> The JNDI configuration does not work. 
> Here's a link to the discussion that may have additional information.
> http://mail-archives.apache.org/mod_mbox/logging-log4j-user/201408.mbox/%3cCACmp6kqNR2c6m3unCKuCH=zuRRS63i6Kn8eFWxHBDUK1yTK--A@mail.gmail.com%3e


--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org