commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ceki Gülcü <>
Subject Re: Resisting the temptation
Date Fri, 10 May 2002 18:43:45 GMT
At 13:17 10.05.2002 -0400, Geir Magnusson Jr. wrote:

>The real problem is the digester dependency on logging, isn't it?

It's one of the problems, perhaps the most interesting one but not
the only one. Other problems are the increase in the number of
necessary jar files, JDK compatibility issues and most importantly
the increase in complexity of the logging setup.

>A solution I can think of is for log4j to have a services entry in their
>jar's META-INF to be the logger factory for logging.

This is in line with Craig's suggestion about setting Log4jFactory

1) META-INF/services/org.apache.commons.logging.LogFactory"

2) org.apache.commons.logging.LogFactory property in
a "" file

3) org.apache.commons.logging.LogFactory in the system

I think at the least the first 2 are needed because
we might not be running under JDK 1.3.

One simple question that pops up to my mind is the what
will happen if for another jar does the same, for example
logkit. It would be quite hilarious to have internal log4j
messages to be output by logkit. :-)

Another, much more serious worry that I have is the fact that the LogFactory
class keeps track of LogFactories by classloader.  What will happen in an
environment with multiple classloader per application, eg. EAR classloader
parent of WAR classloader, parent of JSP classloader, as is the case in
WebLogic and WebSphere? Doesn't Tomcat and other Servlet containers
pose the same problem, with to classloaders, the WAR classloader and
the JSP classloader? Wouldn't multiple LogFactories, that is multiple logging
environments be loaded in a single application?

What am I missing here?


To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message