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 <[EMAIL PROTECTED]>
A: Nicola Ken Barozzi <[EMAIL PROTECTED]>
Nicola Ken Barozzi a écrit :
>
>From: "Sylvain Wallez" <[EMAIL PROTECTED]>
>>
>> Nicola Ken Barozzi a écrit :
>>>
>>> From: "Sylvain Wallez" <[EMAIL PROTECTED]>
>>>
>>>> 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: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
