cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Carsten Ziegeler <>
Subject [RT] Logging in 2.2
Date Wed, 05 Jan 2005 11:45:27 GMT
 From time to time I'm thinking about how to simplify (if possible)
logging in Cocoon, so here we go again.

Currently we are using logkit for logging. It seems that we are more
or less the only project using logkit; everyone else is either
using log4j or commons-logging.

So, we create a small barrier for new users when it comes to configure
the logging as they are not used to logkit. Ok, this barrier is not
very high but it adds to the barrier Cocoon already has because of
its concepts etc. So, my question is, can or should we lower this barrier?

In the past we had several arguments about why logkit is better and so 
on but I think most of these arguments are not valid any more.

We currently use the LogEnabled and Logger interface from the Avalon
Framework - these are not tied to any logging api. The interfaces
provide us IoC for logging.
Avalon provides a LoggerManager to plug in different logging apis,
by default we ship the manager for logkit, but it's possible to
use log4j etc. as well - but this requires additional configuration.

Now, a first and simple step could be to configure log4j as the default
and only those who really want to use logkit can change the 
configuration. There were mainly two complaints about log4j: performance
and configuration features. Now, as we are using the Logger interface
from Avalon, we have a wrapper around the log4j logger anyway and
we can solve the performance problems in the wrapper. In fact,
this wrapper is already available. In addition we have a LoggerManager
that can read configuration files and replace placeholders with
current values, so we have the same features we have in our logkit.xconf.

But we could go further: we have a famous "hunt for removing all core 
dependencies", so what about removing the dependency to Logkit completly?
I think it's sufficient to support one of the "standard" logging apis,
log4j or commons-logging (don't know which one is better), and that's it.
A very wired idea would be to use jdk1.4 logging, but I guess this
is too wild.
Why do we really need logkit? I honestly don't know.

The last step for me would be to remove the dependency to LogEnabled
(while still supporting it of course). I think we should decide for
the *one* logging api to use and provide an IoC way for this api.
Instead of using an own interface like LogEnabled, we support setter
and constructor injection. So if a component has a setLogger()
method for example, we pass a logger on construction. With ECM++
in place this is a piece of cake.

So my plan would be:
1. Decide for one logging api (log4j or commons-logging)
2. Remove the support for all other logging apis
3. Provide a IoC way for logging
4. Slowly move away from LogEnabled

If we still want to provide flexibility, we could opt for 
commons-logging. In this case, brave users can configure logkit as the
logger for commons-logging and they are happy as well.

PS: Although I mention the "remove all dependencies" motivation, the
most important motivation for me is to simplify things - we shouldn't
make things too complicated.


View raw message