commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ceki Gülcü <>
Subject Re: commons-logging auto-detection WAS: [logging] Enterprise
Date Mon, 27 Dec 2004 11:43:34 GMT
At 09:55 AM 12/27/2004, Henning P. Schmiedehausen wrote:
>Ceki =?iso-8859-1?Q?G=FClc=FC?= <> 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
> 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]?


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

>         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:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message