commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ceki Gülcü <>
Subject Re: [logging] Enterprise Common Logging... dare we say 2.0?
Date Thu, 16 Dec 2004 14:49:23 GMT
On 2004-12-16 8:29:31, "Henning P. Schmiedehausen" wrote:

 > [1] If we went down the path that Ceki has for years lobbied for,
 > today it would be "tomcat ships with log4j 1.2.x and your app requires
 > log4j 1.3.x,, leading to all kinds of interesting classloader issues
 > and general nightmarish behaviour." today... :-)

For logging within an app server like Tomcat, the log4j team
recommends the installation of a single copy of log4j.jar in
TOMCAT_HOME/common/lib/. This log4j.jar file will be loaded only once
in memory, shared by the application server *and* all applications
desiring to use log4j for their logging, with the separation of
logging contexts ensured by a repository selector [1, 2, 3] based on
JNDI. Applications desiring to use a different logging API remain

Given that log4j versions change quite slowly with almost few rare
backward compatibility problems, one could imagine that an application
server, say WildCat, could easily move to the latest official version
of log4j without significant trouble.

Now, in the possible but relatively infrequent event where the
customer's application using log4j version 'k' is deployed on an older
version of WildCat dependent on log4j version k, with k < n, the
customer has several options. First, it should be possible to just
drop and replace log4j version n with version k at the level of
WILDCAT_HOME/common/lib. If that is not possible, then the customer
can bundle log4j version n within the application's war file. Note
that the latter solution is more or less where we stand today.

I guess that's enough talk about log4j on this forum.


Ceki Gülcü

   The complete log4j manual:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message