cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Carsten Ziegeler <>
Subject Re: [RT] Logging in 2.2
Date Thu, 06 Jan 2005 08:10:43 GMT
Sylvain Wallez wrote:
> Carsten Ziegeler wrote:
> 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);
Yes, the performance problem is in Log4j - but the log4j wrapper for
LogEnabled covers this problem. It detects on initialization the current
log level and stores this information locally. So a call to 
isDebugEnabled is directly answered by 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.
> Sorry, I don't follow you here. What is this placeholder feature?
You can use properties like ${context-root} in the log4j configuration.

>> 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.
We are trying to move away from the avalon interfaces. Yes, sure 
LogEnabled and Logger are not tied to logkit, but we ship logkit by 
default - all our configuration for logging is for logkit. So we depend
on logkit.

>> 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...
Yes, but it's avalon free :) Ok, seriously with setter or constructor
injection your components work in Cocoon, but you can also use them
in spring or whereever because other containers can handle this
kind of injection. It's not bad to be tied to a specific logging api
that everyone is using - but it's bad to be tied to a framework
(avalon) that noone is using.

 > <SNIP/>
> 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.
No no no :) As I said, I don't want to move away from IoC, you can still
set the logger from the outside, so functional organization is still
possible - the only difference is that we move away from LogEnabled
and that we directly use an existing logging api.


View raw message