LogKit or Log4J ? [was Re: Refactoring and correction of error notification]

[Sylvain Wallez <sy...@anyware-tech.com>]

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

Sylvain

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

Nicola Ken Barozzi a écrit :
> 
>From: "Sylvain Wallez" <sy...@anyware-tech.com>
>>
>> Nicola Ken Barozzi a écrit :
>>>
>>> From: "Sylvain Wallez" <sy...@anyware-tech.com>
>>>
>>>> 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 !

<snip-all-other-overquoted-stuff/>

-- 
Sylvain Wallez
Anyware Technologies - http://www.anyware-tech.com

---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org

Re: LogKit or Log4J ? [was Re: Refactoring and correction of error notification]

[Sylvain Wallez <sy...@anyware-tech.com>]

Carsten Ziegeler a écrit :
> 
> <snip-all/>
> 
> And let's not forget about the new logging api of jdk 1.4!
> 
> As we in Cocoon are using Avalon anyway, it seems appropriate
> to use the Avalon logging as well. It may have some disadvantages
> compared with others, it has some advantages over them, but what
> really matters is: It simply works and is fast.
> 
> Problems may only arise when you use Cocoon in an existing
> environment, where other logging frameworks are already in use.
> 
> But, and this is the good news, the Avalon team is of course
> aware of all the other logging frameworks and tries to provide
> solutions for combining them.
> (Please, Berin or Peter correct me if the following is not
> right.)
> The new LogEnabled interface of Avalon abstracts from the
> underlying logging system. So you can use LogKit, Log4j or
> the logging API of JDK 1.4 but always have the same interface
> to this provided by Avalon.

I'm aware of this and this is really a goog thing. But when you have to
choose a concrete implementation, you need to have some comparison facts
to balance the different frameworks (if the framework isn't imposed).

Also, when you manage the logs (rather than just log messages), you need
to understand and use the specifics of the underlying logging system.

> Unfortunately there are some outstanding issues until
> this mechanism can be used in Cocoon. Torsten has already
> committed himself to change Cocoon as soon as Avalon is
> providing everything needed.

Keep up, Torsten !

> And please, if someone wants to start a thread about which
> logging framework is best, please do not use the cocoon mailing
> list for this. Discuss it anywhere else and present us
> the results - and we will see then what we have to do (Sylvain,
> Nicola Ken - don't worry, I don't target at you with this.)

No offense here. Nicola Ken found my analysis interesting, so I wanted
to share it with the list. But having followed some over-hot discussions
between Peter and Ceki on avalon-dev, I certainly don't want to start a
thread on this subject ;)

Sorry for the noise.

Sylvain

-- 
Sylvain Wallez
Anyware Technologies - http://www.anyware-tech.com

---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org

RE: LogKit or Log4J ? [was Re: Refactoring and correction of error notification]

[Carsten Ziegeler <cz...@s-und-n.de>]

<snip-all/>

And let's not forget about the new logging api of jdk 1.4!

As we in Cocoon are using Avalon anyway, it seems appropriate
to use the Avalon logging as well. It may have some disadvantages
compared with others, it has some advantages over them, but what
really matters is: It simply works and is fast.

Problems may only arise when you use Cocoon in an existing
environment, where other logging frameworks are already in use.

But, and this is the good news, the Avalon team is of course 
aware of all the other logging frameworks and tries to provide
solutions for combining them.
(Please, Berin or Peter correct me if the following is not
right.)
The new LogEnabled interface of Avalon abstracts from the 
underlying logging system. So you can use LogKit, Log4j or
the logging API of JDK 1.4 but always have the same interface
to this provided by Avalon.
Unfortunately there are some outstanding issues until
this mechanism can be used in Cocoon. Torsten has already
committed himself to change Cocoon as soon as Avalon is
providing everything needed.

And please, if someone wants to start a thread about which
logging framework is best, please do not use the cocoon mailing
list for this. Discuss it anywhere else and present us 
the results - and we will see then what we have to do (Sylvain,
Nicola Ken - don't worry, I don't target at you with this.)

Carsten 

---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org