When using the standard Java Logging API (e.g. in a standalone Java program, outside of Tomcat), the logging.properties file can have a directive such as .level = FINE which will set the threshold for the root logger. Assuming in this case that the handlers associated with the root logger also have a threshold of FINE (or lower), then FINE log messages passed to the root logger will be output by the handlers (e.g. to the console, or to a file). When using JULI, the ".level = XXX" directive is ignored. The default logging configuration for Tomcat sets the threshold for the root logger's handlers (1catalina.org.apache.juli.FileHandler and java.util.logging.ConsoleHandler) to FINE, so putting ".level = ALL" should be enough to get all FINE (and CONFIG) log messages sent to the console and log files. It doesn't work if JULI is used directly: Logger log = Logger.getLogger("name"); log.fine("Some message"); It also doesn't work if Commons Logging is used (since the Jdk14Logger just delegates the logging to a Java Logging Logger object - Commong Logging "debug" is translated into Java Logging "FINE"): Log log = LogFactory.get("name"); log.debug("Some message"); The workaround for this is to explicitly give a threshold for a lower-level (package-level, for example) logger, and explicitly list the default handlers for this logger. For example: my.logger.level = FINE my.logger.handlers = 1catalina.org.apache.juli.FileHandler, java.util.logging.ConsoleHandler
Hey Richard, I've been bitten by this defect too. AFAICT it is caused by juli's LogManager adding the root logger directly to the classloaders map of loggers, instead of using the addLogger() method which performs some configuration. Here's a patch to the juli source on the 6.0.x tree. It seems to work okay for me, but I can see from reading the code that there are other defects with the way logging configuration is inherited from classloader to classloader and the way configuration is reset. This might solve your problem though. Roger
Created attachment 18430 [details] proposed fix for defect 39627 patch added
Any chance to see this in Tomcat 5.5.21 or Tomcat 6.0.x?
Hi Sebastian, > Any chance to see this in Tomcat 5.5.21 or Tomcat 6.0.x? I'm not sure if you're asking whether the bug is still present in these versions, or if it's fixed in these versions. I've just tested Tomcat 5.5.20 (the latest 5.5 release) and 6.0.7. The bug is still present in 5.5.20, but is fixed in 6.0.7.
Tomcat 6.0.x uses its own version of JULI. Remy Maucherat checked in Roger's patch in July 2006: http://svn.apache.org/viewvc?view=rev&revision=420008 Tomcat 5.5.x must still use the old version of JULI: http://svn.apache.org/viewvc/tomcat/connectors/trunk/juli/src/java/org/apache/juli/
Created attachment 19370 [details] Proposed fix for bug 39627 (Tomcat 5.5) This is an equivalent patch for Tomcat 5.5. It's the same as the 6.0 patch (except I've just removed the info.loggers.put line, instead of commenting it out). I've tested this with Tomcat 5.5.20 and it fixes the bug. The change to the 6.0 JULI code was made well before 6.0 alpha/beta releases started to be produced, so this has actually been fixed since 6.0.0.
To clarify, this new patch should be applied to the Tomcat Connectors project found here: http://svn.apache.org/viewvc/tomcat/connectors/trunk/
Changing back to 5.5.17 (the earliest known version with this bug).
This has been fixed in svn for 5.5.x and will be in 5.5.21 onwards.
Fixed in 5.5.22.
5.5.22 wasn't released so this is fixed in 5.5.23.