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).
WDYT?
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:
https://www.qos.ch/logging/sc.html
There is also an example of how to achieve separation here:
http://cvs.apache.org/viewcvs.cgi/logging-log4j/examples/tiny-webapp/
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.
-- Stefano.
-- Ceki Gülcü
For log4j documentation consider "The complete log4j manual"
ISBN: 2970036908 http://www.qos.ch/shop/products/clm_t.jsp
