]>
By default, only java.util.logging is available for the core Tomcat, as Tomcat uses
a package renamed logging implementation which is hardcoded for that logger. Usage of
alternate loggers is available after building the extra components (see
the extras components documentation), which includes
a full commons-logging implementation.
Tomcat 6.0 uses
Commons Logging
throughout its internal code allowing the
developer to choose a logging configuration that suits their needs, e.g
java.util.logging or
Log4J.
Commons Logging provides Tomcat the ability to log
hierarchially across various log levels without needing to rely on a particular
logging implementation.
An important consequence for Tomcat 6.0 is that the <Logger> element found in
previous versions to create a
Tomcat 6.0 has done away with
If you need to setup cross-context detailed logging from within Tomcat's code,
then you can use a simple log4j configuration. Note that this logging van be very
verbose depending on the log level you chose to use. Note also that a log4j logging
configuration is not going to produce stack trace type logging: those stack traces
are output to
Follow the following steps to setup a file named tomcat.log that has internal
Tomcat logging output to it:
localhost_log is no longer a valid nested element
of <Context>. Instead, the default Tomcat configuration will use java.util.logging.
If the developer wishes to collect detailed internal Tomcat logging (i.e what is happening
within the Tomcat engine), then they should configure a logging system such as java.util.logging
or log4j as detailed next.
localhost_log which you may be familiar with
as the runtime exception/stack trace log. These types of error are usually thrown
by uncaught exceptions, but are still valuable to the developer. They can now be
found in the stdout log.
stdout as discussed above.
log4j.appender.R=org.apache.log4j.RollingFileAppender
log4j.appender.R.File=${catalina.home}/logs/tomcat.log
log4j.appender.R.MaxFileSize=10MB
log4j.appender.R.MaxBackupIndex=10
log4j.appender.R.layout=org.apache.log4j.PatternLayout
log4j.appender.R.layout.ConversionPattern=%p %t %c - %m%n
log4j.logger.org.apache.catalina=DEBUG, R
$CATALINA_HOME/bin/tomcat-juli.jar with
output/extras/tomcat-juli.jar.output/extras/tomcat-juli-adapters.jar in
$CATALINA_HOME/lib.
This log4j configuration sets up a file called tomcat.log in your Tomcat logs folder with a maximum file size of 10MB and up to 10 backups. DEBUG level is specified which will result in the most verbose output from Tomcat.
You can (and should) be more picky about which packages to include in the logging. Tomcat 6 uses defines loggers by Engine and Host names. For example, for a default Catalina localhost log, add this to the end of the log4j.properties above. Note that there are known issues with using this naming convention (with square brackets) in log4j XML based configuration files, so we recommend you use a properties file as described until a future version of log4j allows this convention.
Your web applications should certainly use their own log4j configuration. This is valid with the above configuration. You would place a similar log4j.properties file in your web application's WEB-INF/classes folder, and log4j1.2.8.jar into WEB-INF/lib. Then specify your package level logging. This is a basic setup of log4j which does *not* require Commons-Logging, and you should consult the log4j documentation for more options. This page is intended only as a bootstrapping guide.
The default implemenatation of java.util.logging provided in the JDK is too limited to be useful. A limitation of JDK Logging appears to be the inability to have per-web application logging, as the configuration is per-VM. As a result, Tomcat will, in the default configuration, replace the default LogManager implementation with a container friendly implementation called JULI, which addresses these shortcomings. It supports the same configuration mechanisms as the standard JDK java.util.logging, using either a programmatic approach, or properties files. The main difference is that per-classloader properties files can be set (which enables easy redeployment friendly webapp configuration), and the properties files support slightly extended constructs which allows more freedom for defining handlers and assigning them to loggers.
JULI is enabled by default in Tomcat 6.0, and supports per classloader configuration, in addition to the regular global java.util.logging configuration. This means that logging can be configured at the following layers:
$JAVA_HOME/jre/lib.
Alternately, it can also use a global configuration file located elsewhere by using the
system property java.util.logging.config.file, or programmatic configuration using
java.util.logging.config.class.The default logging.properties specifies a ConsoleHandler for routing logging to stdout and also a FileHandler. A handler's log level threshold can be set using SEVERE, WARNING, INFO, CONFIG, FINE, FINER, FINEST or ALL. The logging.properties shipped with JDK is set to INFO. You can also target specific packages to collect logging from and specify a level. Here is how you would set debugging from Tomcat. You would need to ensure the ConsoleHandler's level is also set to collect this threshold, so FINEST or ALL should be set. Please refer to Sun's java.util.logging documentation for the complete details.
The configuration used by JULI is extremely similar, but uses a few extensions to allow better flexibility in assigning loggers. The main differences are:
22foobar. is a valid prefix.loggerName.handlers
property.loggerName.useParentHandlers property, which accepts
a boolean value..handlers property.
Example logging.properties file to be placed in common/classes:
Example logging.properties for the servlet-examples web application to be placed
in WEB-INF/classes inside the web application: