cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <>
Subject Re: [RT] Logging in 2.2
Date Wed, 05 Jan 2005 22:25:48 GMT
Carsten Ziegeler wrote:

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

We are not using logkit: we are using Avalon Logger, and the default 
configuration shipped with Cocoon use the LogKit implementation of 
Avalon Logger (you say the same below).

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

Why? What has changed?

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

Nono, the performance problem is in Log4J itself: checking if a log 
level is enabled on a category is costly and involves crawling up the 
category tree up to finding an ancestor which has an explicit setting 
for this (see Category.isDebugEnabled and Category.getEffectiveLevel);

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

Sorry, I don't follow you here. What is this placeholder feature?

> But we could go further: we have a famous "hunt for removing all core 
> dependencies", so what about removing the dependency to Logkit completly?

Again, we have a dependency on the Avalon Logger API, not to a 
particular logger API. That's exactly the same for the Service Manager.

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

Because it's not bloated?

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

Doesn't LogEnabled provide an implementation-independent IoC way?

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

How's that really different from LogEnabled? The object will still be 
tied to the Logger interface, which lives just beside LogEnabled...

> So my plan would be:
> 1. Decide for one logging api (log4j or commons-logging)

IMO, log4j and commons-logging cannot be compared : log4j is an 
implementation whereas commons-logging is an abstract API which 
provides, among others, and implementation based on log4j.

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

Then maybe it's just a matter of changing the syntax of logkit.xconf?

Your proposal omits an important point: why do we use IoC loggers? The 
classical way of getting a Category in log4j is to use :
    private static Logger logger = Logger.getLogger(Blah.class);

That leads to a topological organization of logger hierarchies (it's the 
class name) whereas IoC-style logger the way we do it using the "logger" 
attribute allows for a functional organization of hierarchies, as we can 
group logs of related components into a single category whatever their 
class name, thus easing filtering.

Furthermore, logkit (the implementation, not the Avalon Logger API) also 
provides the topological information by allowing to output the name of 
the calling class along with the category.

So, my POV on this is:
- we use Avalon Logger that can be mapped to logkit, log4j, whatever.
- I'm happy with logkit although I don't want to refrain people to use 
something else
- I certainly don't want to start again something similar to the 
migration from Loggable (logkit-specific) to LogEnabled (not talking 
also of Composable to Serviceable).


Sylvain Wallez                                  Anyware Technologies 
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }

View raw message