Yes, the performance problem is in Log4j - but the log4j wrapper forCarsten 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);
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.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 dependBut 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.
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.
Carsten
