cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <>
Subject LogKit or Log4J ? [was Re: Refactoring and correction of error notification]
Date Fri, 04 Jan 2002 10:39:35 GMT
Forwarding to the list a message I sent privately to Nicola Ken (didn't
notice the reply-to header) that he found interesting for choosing
between LogKit and Log4J...


-------- Original Message --------
Objet: Re: Refactoring and correction of error notification
Date: Thu, 03 Jan 2002 18:14:44 +0100
De: Sylvain Wallez <>
A: Nicola Ken Barozzi <>

Nicola Ken Barozzi a écrit :
>From: "Sylvain Wallez" <>
>> Nicola Ken Barozzi a écrit :
>>> From: "Sylvain Wallez" <>
>>>> Nicola Ken Barozzi a écrit :
>>>> OK. So I propose system-wide categories. They imply more development in
>>>> the Cocoon core, but provide the cleanest way for filtering.
>>> +1
>>> If you can work on this, I'll take care of the output part (see below).
>> I'll make a proposal soon. In order for it to be both speedy and
>> available from every place in the code, I think we will need a component
>> with a set of static accessor to static loggers. I know static variables
>> are a bad thing, but looking up a regular component will certainly kill
>> performance.
> Hey, now why not use log4j?
> It has static accessors... I don't understand why Avalon made his own version.
> It stopped the testlet stuff because JUnit was way ahead, why then not use log4j?
> What is needed that it cannot provide?
> Ok Mr. Donald, don't hit me too hard on this ;-P

I will, but not so hard as Peter or Berin ;)

The main thing is about IOC (inversion of control) : a component
shouldn't fetch what it needs from its environment, but the environment
must give it what it needs. This has several advantages :

- security : if no-one has access to your logger, no-one can write fake
messages in it. This may seem an integrist approach for logging, but
think what happens if the LogTarget sends a SMS to an admin when errors
occur in certain categories. Malicious code (e.g. a user XSP) could
forbid sleep to your sysadmin ;)

- configurability : have you noticed the "logger" attribute that you can
place on component declarations in xconf and sitemap ? This allows to
manage externally your logging categories. If the category name is
hard-coded in the component, you cannot manage the category space.

Now about Log4J : some people here started using log4j on some projects,
just because "it was known". Since all our projects are cocoon-based, I
compared LogKit and Log4J. The results where that Log4J is (I may be
flamed for this) badly designed : class names and organization are IMO
non intuitive, and more important, logging is *slow* by design compared
to what LogKit can achieve.

Look for example at Category.callAppenders() : logging an event iterates
on all parents of a Category to call the various appenders and each
iteration has a synchronized block !!! LogKit on the contrary uses the
fact that changing targets occurs less often than logging (if it never
happens) and propages targets of a Logger to child Loggers so they have
all targets at hand for maximum efficiency.

And LogKit also has static accessors : just use
Hierarchy.getDefault().getLoggerFor("my.category"). But LogKitManager
can prevent this by creating its own hierarchy, not statically
available, thus securing it.

With this analysis, it was easy to make people switch from Log4J to
LogKit !


Sylvain Wallez
Anyware Technologies -

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

View raw message