cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ceki Gülcü <>
Subject Re: [RT] Logging in Cocoon
Date Thu, 27 May 2004 17:37:45 GMT
At 07:06 PM 5/27/2004, Stefano Mazzocchi wrote:
>Carsten Ziegeler wrote:
>>Many have suggested this in the past and as Ugo mentioned it
>>yesterday, I think it's time to check our logging strategy.
>>Currently we use LogKit as our base logging system. Unfortunately
>>we are using third party components that either use Log4J or
>>commons-logging. So in the end you have to configure more than
>>one logging system.
>>Log4j is the standard for logging  - I think this is obvious. So, the 
>>easiest and most obvious solution is to use Log4J in
>>Cocoon as well.
>>Since 2.1.5 you can simply switch to Log4J if you configure
>>the logger-class parameter in web.xml. There is only one
>>drawback: log4j has to be configured "elsewhere"; this is
>>not done by Cocoon.
>>So, my suggestion is to:
>>- deprecate the use of LogKit
>>- switch to log4j as default
>>- make it possible to configure log4j from within Cocoon (like the
>>   current logkit.xml for LogKit).
>The reason why logkit was developped was because log4j made extensive use 
>of static methods and that doesn't work very well with servlet environments.

The static factory methods are syntactic sugar, or syntactic vinegar
depending on your pov.

If you control have control over your applications, you can use
separate logger repositories if you wish to do so. If you use the
JNDIContextSelector, log4j can even automatically manage the
repositories for you.

This is known as the logging separation problem. It is discussed here:

There is also an example of how to achieve separation here:

I hope the above is relevant and makes sense.

>Ceki, anything to report on that front?

Since you asked, log4j will soon be using itself for its own
logging. Thus, log4j will restrict itself to the logging context in
effect. So multiple applications will be able to share the same
log4j.jar file, but have completely separate logging output where even
log4j's own logging will be restricted to the application's logging
context. The self-logging property is *vaguely* similar to XML being a
self-describing language.

In short we are pushing the LoggerRepository idea to its limits, even
from within log4j itself.

>NOTE: Cocoon is getting fed up with avalon and its community instabilities 
>and we'd like to move away from it as much as possible.

In Avalon's defense I can say that it is far from trivial to ensure
stability over the years.


Ceki Gülcü

      For log4j documentation consider "The complete log4j manual"
      ISBN: 2970036908  

View raw message