You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by "Henning P. Schmiedehausen" <hp...@intermeta.de> on 2004/12/27 09:55:09 UTC
Re: commons-logging auto-detection WAS: [logging] Enterprise
Ceki =?iso-8859-1?Q?G=FClc=FC?= <ce...@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
Re: commons-logging auto-detection WAS: [logging] Enterprise
Posted by Ceki Gülcü <ce...@qos.ch>.
At 09:55 AM 12/27/2004, Henning P. Schmiedehausen wrote:
>Ceki =?iso-8859-1?Q?G=FClc=FC?= <ce...@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, [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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org