archiva-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joakim Erdfelt <joa...@erdfelt.com>
Subject Logging Fight! (and suggestion) - Was: Re: FYI: de-plexus-utils'ing
Date Tue, 05 Dec 2006 22:26:33 GMT
ooh! Logging fight! logging fight! ;-)

(Jason and I argue about this constantly)

Paul Hammant's blog entry - http://paulhammant.com/blog/000241.html

He was railing on about...
* Instantiating logging using IoC techniques.
* Using static logging in a component.
* Logging is mostly never read.

He recommends ...
* Creating a Monitor in your IoC managed component instead of using
static logging.

(Everything from here down is my opinion. so be careful how you
attribute it!)

What he doesn't say ...
* static logging is an anti-pattern.
* using monitor interface in non-components.
* Recommends, or makes an attempt to address the use of legacy apis.
 For those (thousands) of apis, jars, non-components, etc that already
use logging, we are stuck.
* Monitor interface proliferation.  (static = 1 way to do it, monitor =
n+1 ways)
* Monitor interface nesting. (a component with a monitor that needs to
use another component with a different monitor)
* Monitor interface memory issues. (the static logging kings log4j,
jdk-logging, commons-logging, slf4j, etc.. have far far far lower memory
utilization than using the monitor interface pattern)
* Monitor interface performance. (logging is *very* important, about as
important as configuration, some organizations prize the log output,
collect it, back it up, aggregate it, send it to data warehouses,
produce reports, evaluation health of app based on logging, etc. 
Monitor interface pattern is notoriously bad for performance when
compared to static logging alternatives)
* Monitor interface concurrency issues. (static loggers log4j,
jdk-logging, take great lengths to be thread-safe and support large
volume logging that the monitor interface pattern does not address.)

- commons-logging -
commons-logging has been pegged with ClassLoader issues for a long time.
Fact is, commons-logging has been a victim of a horrendously bad
Exception message.
An exception message that was expanded and corrected in commons-logging
1.0.4.
The true nature of the perceived "ClassLoader" issues are revealed in
all their glory starting with 1.0.4.

commons-logging 1.1 introduced a more comprehensive set of checks and
exceptions to help you identify the root cause of most of the
commons-logging headaches (configuration!, not classloader, not
classpath, not even the commons-logging.jar vs commons-logging-api.jar
debate.)

- Suggestion: slf4j & plexus -
We should rip out all of commons-logging & log4j & jdk-logging efforts
within plexus.
We should write all of our logging against slf4j.
Then we can stop bickering about logging. let slf4j deal with the
configuration of the other loggers in a real-world application (like
maven and archiva) which inevitably use all 4 logging APIs AT THE SAME TIME.

- Joakim


Jason van Zyl wrote:
>
> On 5 Dec 06, at 12:23 PM 5 Dec 06, Henri Yandell wrote:
>
>> On 12/3/06, Jason van Zyl <jason@maven.org> wrote:
>>> On 3 Dec 06, at 11:29 PM 3 Dec 06, Carlos Sanchez wrote:
>>>
>>> > I think something like http://www.slf4j.org/ can allow using
>>> libraries
>>> > that use commons-logging without getting its problems
>>> >
>>>
>>> I didn't see it in there anyway, but the problem is not only that
>>> commons-logging is a piece of crap
>>
>> My understanding is that the classloader issues have been worked out
>> in the 1.1 release.
>>
>
> Classloader issues aside it's still a piece of crap. Static logging is
> bad and is an anti-pattern for component-based programming. Causes
> nothing but grief. I know you can use commons-logging as a monitor but
> no one does that. Paul Hammant's blog on why static logging is crap is
> a good read.
>
>>> , but that people also abuse it and
>>> put logging in libraries when they should be throwing exceptions and
>>> be tested properly so you know what it does and so you don't have to
>>> stick logging in a library which is just plain dumb.
>>
>> DBCP and FileUpload are two where I can see that I would want to log,
>> but for most libraries I don't see the need. IO and Lang (two I've
>> introduced so far) don't use logging.
>
> You want to test, have a monitor or eventing system so that you can
> get anything important to go to a console, some form or GUI, or a log
> file if you like. Going straight to logging is the extremely limited
> and makes integration a pain in the ass.
>
>>
>> Hen
>>
>



Mime
View raw message