commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Henning P. Schmiedehausen" <...@intermeta.de>
Subject Re: commons-logging auto-detection WAS: [logging] Enterprise
Date Mon, 27 Dec 2004 08:55:09 GMT
Ceki =?iso-8859-1?Q?G=FClc=FC?= <ceki@qos.ch> 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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message