At 09:55 AM 12/27/2004, Henning P. Schmiedehausen wrote:
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, [1] says:
1) automated classloader-based discovery mechanisms cause a lot of
headaches and can be health hazard
2) don't assume diverging APIs can be abstracted away.
So in what way [1] is in contradiction with [2, 3, 4]?
[1] http://www.qos.ch/logging/thinkAgain.jsp
[2] http://wiki.custine.com/display/ENV/Log4j+1.3+and+Tomcat5
[3] http://cvs.apache.org/viewcvs.cgi/logging-log4j/examples/tiny-webapp/
[4] http://www.qos.ch/logging/sc.jsp
I am extremely curious to know in what way two documents written by
me, around the same time, contradict each other.
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]
Well, log4j 1.3 is still in alpha. We still have time to address the
o.a.l.RollingFileAppender compatibility problem before 1.3 goes RC.
IMHO you shouldn't argue on both sides of the fence.
In what way was I arguing 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.
The model suggested in [2] allows for greater control over the logging
environment. It was developed in response to demand from the
developers of various Application Servers, in particular Tomcat. You
are of course free to characterize it as "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.
Agreed. Another point to keep in mind is that logging should help
solve problems and not be the source of bugs obfuscating problem
diagnosis.
Regards
Henning
[1] If you think, this is a constructed example, you might want to
read velocity-dev.
...and what was their conclusion?
--
Ceki G�lc�
The complete log4j manual: http://qos.ch/log4j/
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
