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 unaffected.
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.
[1] http://wiki.custine.com/display/ENV/Log4j+1.3+and+Tomcat5 [2] http://cvs.apache.org/viewcvs.cgi/logging-log4j/examples/tiny-webapp/ [3] http://www.qos.ch/logging/sc.jsp
-- Ceki G�lc�
The complete log4j manual: http://qos.ch/log4j/
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
