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 in 1) META-INF/services/org.apache.commons.logging.LogFactory" 2) org.apache.commons.logging.LogFactory property in a "commons-logging.properties" file 3) org.apache.commons.logging.LogFactory in the system properties 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? -- Ceki -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
