From a Geronimo perspective, since commons-logging already has a trace level, we could just trash any log4j code from Geronimo for now.
The Commons Logging log4j adapter does TRACE at DEBUG right now because
Log4J doesn't have a TRACE level. Dain suggested that we add an extended
level for TRACE to Commons Logging. Others have said that they would like
to see Log4J address it directly. Whatever solution comes from the
discussion between the projects is probably fine. The important things are
(a) improved collaboration, and (b) the solution.
commons-logging is now relied upon by a lot of projects. this means that we have to be pretty conservative about changes. there are some subtle choices concerning classloading which are required for commons-logging to function correctly in servlet containers (such as tomcat) but make it difficult to solve some other common user issues.
so, i'd probably advise against using using commons-logging directly.
i'd say that the basic commons logging interface (Log) is pretty much optimal. the LogFactory interface is basically sound but the implementation is over-complicated due to needs to allow independent configurations for different context classloaders.
my personal recommendation would be that geronimo considers using the extensive research done and experience gained by the commons-logging team but uses a repackaged version with a modified LogFactory implementation. this implementation should probably be configurable (by JMX, say) rather than relying on the complex configuration mechanisms employed by the commons-logging implementation.
this would isolate the container logging from issues with loggers in contained application.
i would also recommend that a separate Log implementation be created that extends Log4JLogger maps trace to a log4j level.
- robert
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
