Ceki =?iso-8859-1?Q?G=FClc=FC?= <[EMAIL PROTECTED]> writes: >Log4j is slowly migrating to a model where there will be only a single >log4j.jar installed per Application Server. This single copy will be >installed under the ./common/lib or ./lib/ directories. See [1, 2, 3] for >further details.
This approach is doomed to fail. This is the approach that was first tried with JCL and strongly argued against by some log4j people. See http://www.qos.ch/logging/thinkAgain.jsp for details. In a nutshell: My webapp _requires_ log4j-a.b.c.jar and your container provides log4j-x.y.z.jar in common/lib. E.g. I _require_ org.apache.log4j.RollingFileAppender from log4j-1.2.8.jar [1] Either I can do some class loader magic, that I get that right or my app fails. Which is then your fault. :-) IMHO you shouldn't argue on both sides of the fence. Personally, I prefer to let every application bring its own jars and be able to completely isolate the jars used by the container from the jars used by the application. Which is possible with Tomcat and renders your "model" useless. At some point, you want to understand, that logging, like configuration or a web framework is a minor part of a larger app and that it has to subordinate to its requirements. Logging cannot dictate the way that an application is written. If it tries to, developers will use another library. Regards Henning [1] If you think, this is a constructed example, you might want to read velocity-dev. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
