DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://issues.apache.org/bugzilla/show_bug.cgi?id=33143>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=33143 Summary: [PATCH] Java 1.4 loggers per context Product: Tomcat 5 Version: Unknown Platform: All OS/Version: All Status: NEW Keywords: PatchAvailable Severity: enhancement Priority: P5 Component: Unknown AssignedTo: tomcat-dev@jakarta.apache.org ReportedBy: [EMAIL PROTECTED] A potential problem for webapps using the java.util.logging API is that loggers are usually global over the entire JVM, rather than per-context as we might prefer. Say you have a single Tomcat server with two webapps. Each webapp includes it's own copy of foo.jar in WEB-INF/lib. foo.jar uses a standard idiom for naming loggers: package com.acme.foo; import java.util.logging.*; public class SomeClass { public static final Logger logger = Logger.getInstance(SomeClass.class.getName()); ... } So each webapp has it's own classloader with it's own copy of SomeClass. The problem is that both classes end up with a reference to the same Logger instance. If both webapps attach their own handler to the Logger, their handler will receive log events from the other webapp. Say each webapp has it's own log file handler, you'll see every log message written to *both* the log files. There's nothing you can do in the webapp or handler to fix this, as there's no way to tell which context a particular LogRecord object came from. Log4j avoids this issue completely, as the entire logging system is contained within the servlet context's ClassLoader. Java logging is loaded via the system classloader, however, so loggers end up being global to the JVM. I think it is fair to class this as a failing on the Java logging system when using it inside any sort of container (serlvet, EJB, or other). I can only find one small reference to this issue in the docs. The javadoc for the constructor of LogManager says: "Protected constructor. This is protected so that container applications (such as J2EE containers) can subclass the object. It is non-public as it is intended that there only be one LogManager object, whose value is retrieved by calling Logmanager.getLogManager." Which seems to indicate that Sun expect servlet containers to provide their own LogManager implementation that provides the behaviour the container wants. In Tomcat's case, I think the desired behaviour is for Loggers to be instantiated per servlet context. So, I have written a LogManager implementation that does this. Is basically splits the Logger namespace up based on the classloader returned by Thread.currentThread().getContextClassLoader(). This seems to do exactly what I want under Tomcat 5.0.x. Please see the attached source. The problem is that the standard LogManager can only be replaced at JVM startup. A webapp can't do it. The procedure is to put the replacement LogManager in a jar, add that jar to the system classpath, and specify the LogManager's class name in the system property "java.util.logging.manager". I suggest that Tomcat should use this replacement LogManager, as having per-context loggers provides much better behaviour inside a container. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
