I see no reason to switch from using the LogKit LoggerManager interface. Changing the newLoggerManager() method in CocoonServlet to default to LOG4J and also provide an easy way to use the LogKitLoggerManager is trivial. Anyone who wants to "try out" Log4j in 2.1.5 only needs to define "logger-class" as "LOG4J" in web.xml as an init parm. In addition, logger-class can specify any class that implements LogKit's LoggerManager interface - which is why I submitted the patch.

What more support do you need than that? Are you thinking that Log4j's default configuration techniques are not sufficient?

Ralph

At 6/7/2004 11:44 PM, you wrote:
Ok, the recent thread about using log4j as the default
showed that there is a big interest in directly using log4j.

Sylvain raised the concern of performance which can imho
be solved in the wrapper class. The avalon logging uses
a wrapper class around the log4j logger to conform to
the avalon Logger interface. This wrapper can store/cache
the level in an instance variable making the test
calls to isDebugEnabled() etc. as fast as possible.
Although this is an optimization in the nano area which
should neither increase/decrease performance for a
complete Cocoon request, it should solve the concern.

Now, imho only two questions remain :)

1. What should Cocoon offer to support log4j? So, everyone
out there who wants to use/is using log4j with Cocoon, what
are you missing? Examples could be, a support for configuring
log4j via Cocoon etc.

2. Should we make log4j (with the improved wrapper idea from
above) the default?

WDYT?

Carsten

Carsten Ziegeler
Open Source Group, S&N AG
http://www.osoco.net/weblogs/rael/



Reply via email to