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
-- Sylvain Wallez Anyware Technologies http://www.apache.org/~sylvain http://www.anyware-tech.com { XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
