Apache Tomcat 6.0 - Logging in Tomcat

Logging in Tomcat

Logging in Apache Tomcat is implemented with the help of Apache Commons Logging library. That library is a thin wrapper above different logging frameworks. It provides Tomcat with the ability to log hierarchically across various log levels without the need to rely on a particular logging implementation.

Since Tomcat 6.0, Tomcat uses a private package-renamed implementation of Apache Commons Logging, to allow web applications to use their own independent copies of the original Apache Commons Logging library. In the default distribution this private copy of the library is simplified and hardcoded to use the java.util.logging framework.

To configure Tomcat to use alternative logging frameworks for its internal logging, one has to replace the logging library with the one that is built with the full implementation. Such library is provided as an extras component. Instructions on how to configure Tomcat to use Log4j framework for its internal logging may be found below.

A web application running on Apache Tomcat can:

Use logging API provided by the Java Servlets specification, javax.servlet.ServletContext.log(...)

Use system logging API, java.util.logging.

Use any logging framework of its choice.

The logging frameworks used by different web applications run independently of each other. See class loading for more details. The exception to this rule is java.util.logging, if it used directly or indirectly by your logging library. That is because it is loaded by the system and is shared across web applications.

Apache Tomcat has its own implementation of several key elements of java.util.logging API. This implementation is called "JULI". The key component there is a custom LogManager implementation, that is aware of different web applications running on Tomcat (and their different class loaders). It supports private per-application logging configurations. It is also notified by Tomcat when a web application is unloaded from memory, so that the references to its classes can be cleared, preventing memory leaks. This java.util.logging implementation is enabled by providing certain system properties when starting Java. The Apache Tomcat startup scripts do this for you, but if you are using different tools to run Tomcat (such as jsvc, or running Tomcat from within an IDE), you should take care of them by yourself. More details about Tomcat JULI may be found below.

The calls to javax.servlet.ServletContext.log(...) to write log messages are handled by internal Tomcat logging. Such messages are logged to the category named
org.apache.catalina.core.ContainerBase.[${engine}].[${host}].[${context}]
This logging is performed according to the Tomcat logging configuration. You cannot overwrite it in a web application.

Old applications that still use System.out or System.err can be tricked, by setting swallowOutput attribute on a Context. If the attribute is set to true, calls to System.out/err during request processing will be intercepted, and their output will be fed to the logging subsystem using the javax.servlet.ServletContext.log(...) calls.
Note, that this feature is actually a trick, and works only with direct calls to System.out/err, and only during request processing cycle. It cannot be used to intercept logging frameworks that themselves write to the system streams, as those start early and may obtain a direct reference to the streams.

The default logging configuration in Apache Tomcat writes the same messages to the console and to a log file. This is great when using Tomcat for development, but usually is not needed in production. When running Tomcat on unixes, the console output is usually redirected to a file named catalina.out. The name is configurable using an environment variable. (See the startup scripts). Whatever is written to System.err/out will be logged in that file. That may include:

Thread dumps, if you requested them via a system signal

Uncaught exceptions printed by java.lang.ThreadGroup.uncaughtException(..)

When running as a service on Windows, the console output is also caught and redirected, but the file names are different.

A related, but different feature is access logging. It can be configured as a valve at the Context, or Host, or Engine. See Valves documentation for more details.

Using java.util.logging (default)

The default implementation 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, 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:

In the JDK's logging.properties file. Check your JAVA_HOME environment setting to see which JDK Tomcat is using. The file will be in $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.

In each classloader using a logging.properties file. This means that it is possible to have a configuration for the Tomcat core, as well as separate configurations for each webapps which will have the same lifecycle as the webapps.

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.
org.apache.catalina.level=FINEST
The configuration used by JULI is extremely similar, but uses a few extensions to allow better flexibility in assigning loggers. The main differences are:

A prefix may be added to handler names, so that multiple handlers of a single class may be instantiated. A prefix is a String which starts with a digit, and ends with '.'. For example, 22foobar. is a valid prefix.

As in Java 6.0, loggers can define a list of handlers using the loggerName.handlers property.

By default, loggers will not delegate to their parent if they have associated handlers. This may be changed per logger using the loggerName.useParentHandlers property, which accepts a boolean value.

The root logger can define its set of handlers using a .handlers property.

Logging is not buffered by default. To configure buffering, use the bufferSize property of a handler. A value of 0 uses system default buffering (typically an 8K buffer will be used). A value of <0 forces a writer flush upon each log write. A value >0 uses a BufferedOutputStream with the defined value but note that the system default buffering will also be applied.

System property replacement is performed for property values which contain ${systemPropertyName}.

Example logging.properties file to be placed in $CATALINA_BASE/conf:
handlers = 1catalina.org.apache.juli.FileHandler, \
           2localhost.org.apache.juli.FileHandler, \
           3manager.org.apache.juli.FileHandler, \
           4admin.org.apache.juli.FileHandler, \
           java.util.logging.ConsoleHandler

.handlers = 1catalina.org.apache.juli.FileHandler, java.util.logging.ConsoleHandler

############################################################
# Handler specific properties.
# Describes specific configuration info for Handlers.
############################################################

1catalina.org.apache.juli.FileHandler.level = FINE
1catalina.org.apache.juli.FileHandler.directory = ${catalina.base}/logs
1catalina.org.apache.juli.FileHandler.prefix = catalina.

2localhost.org.apache.juli.FileHandler.level = FINE
2localhost.org.apache.juli.FileHandler.directory = ${catalina.base}/logs
2localhost.org.apache.juli.FileHandler.prefix = localhost.

3manager.org.apache.juli.FileHandler.level = FINE
3manager.org.apache.juli.FileHandler.directory = ${catalina.base}/logs
3manager.org.apache.juli.FileHandler.prefix = manager.

4admin.org.apache.juli.FileHandler.level = FINE
4admin.org.apache.juli.FileHandler.directory = ${catalina.base}/logs
4admin.org.apache.juli.FileHandler.prefix = admin.
4admin.org.apache.juli.FileHandler.bufferSize = 16384

java.util.logging.ConsoleHandler.level = FINE
java.util.logging.ConsoleHandler.formatter = java.util.logging.SimpleFormatter


############################################################
# Facility specific properties.
# Provides extra control for each logger.
############################################################

org.apache.catalina.core.ContainerBase.[Catalina].[localhost].level = INFO
org.apache.catalina.core.ContainerBase.[Catalina].[localhost].handlers = \
   2localhost.org.apache.juli.FileHandler

org.apache.catalina.core.ContainerBase.[Catalina].[localhost].[/manager].level = INFO
org.apache.catalina.core.ContainerBase.[Catalina].[localhost].[/manager].handlers = \
   3manager.org.apache.juli.FileHandler

org.apache.catalina.core.ContainerBase.[Catalina].[localhost].[/admin].level = INFO
org.apache.catalina.core.ContainerBase.[Catalina].[localhost].[/admin].handlers = \
   4admin.org.apache.juli.FileHandler

# For example, set the org.apache.catalina.util.LifecycleBase logger to log
# each component that extends LifecycleBase changing state:
#org.apache.catalina.util.LifecycleBase.level = FINE
    
Example logging.properties for the servlet-examples web application to be placed in WEB-INF/classes inside the web application:
handlers = org.apache.juli.FileHandler, java.util.logging.ConsoleHandler

############################################################
# Handler specific properties.
# Describes specific configuration info for Handlers.
############################################################

org.apache.juli.FileHandler.level = FINE
org.apache.juli.FileHandler.directory = ${catalina.base}/logs
org.apache.juli.FileHandler.prefix = servlet-examples.

java.util.logging.ConsoleHandler.level = FINE
java.util.logging.ConsoleHandler.formatter = java.util.logging.SimpleFormatter
      

Using Log4j

This section explains how to configure Tomcat to use log4j rather than java.util.logging for all Tomcat's internal logging. The following steps describe configuring log4j to output Tomcat's internal logging to a file named tomcat.log.

Create a file called log4j.properties with the following content and save it into $CATALINA_HOME/lib.
log4j.rootLogger=INFO, CATALINA

# Define all the appenders
log4j.appender.CATALINA=org.apache.log4j.DailyRollingFileAppender
log4j.appender.CATALINA.file=${catalina.base}/logs/catalina.
log4j.appender.CATALINA.encoding=UTF-8
# Roll-over the log once per day
log4j.appender.CATALINA.DatePattern='.'yyyy-MM-dd'.log'
log4j.appender.CATALINA.conversionPattern = %d [%t] %-5p %c- %m%n
log4j.appender.CATALINA.append=true

log4j.appender.LOCALHOST=org.apache.log4j.DailyRollingFileAppender
log4j.appender.LOCALHOST.file=${catalina.base}/logs/localhost.
log4j.appender.LOCALHOST.encoding=UTF-8
log4j.appender.LOCALHOST.DatePattern='.'yyyy-MM-dd'.log'
log4j.appender.LOCALHOST.conversionPattern = %d [%t] %-5p %c- %m%n
log4j.appender.LOCALHOST.append=true

log4j.appender.MANAGER=org.apache.log4j.DailyRollingFileAppender
log4j.appender.MANAGER.file=${catalina.base}/logs/manager.
log4j.appender.MANAGER.encoding=UTF-8
log4j.appender.MANAGER.DatePattern='.'yyyy-MM-dd'.log'
log4j.appender.MANAGER.conversionPattern = %d [%t] %-5p %c- %m%n
log4j.appender.MANAGER.append=true

log4j.appender.HOST-MANAGER=org.apache.log4j.DailyRollingFileAppender
log4j.appender.HOST-MANAGER.file=${catalina.base}/logs/host-manager.
log4j.appender.HOST-MANAGER.encoding=UTF-8
log4j.appender.HOST-MANAGER.DatePattern='.'yyyy-MM-dd'.log'
log4j.appender.HOST-MANAGER.conversionPattern = %d [%t] %-5p %c- %m%n
log4j.appender.HOST-MANAGER.append=true

log4j.appender.CONSOLE=org.apache.log4j.ConsoleAppender
log4j.appender.CONSOLE.encoding=UTF-8
log4j.appender.CONSOLE.conversionPattern = %d [%t] %-5p %c- %m%n

# Configure which loggers log to which appenders
log4j.logger.org.apache.catalina.core.ContainerBase.[Catalina].[localhost]=INFO, LOCALHOST
log4j.logger.org.apache.catalina.core.ContainerBase.[Catalina].[localhost].[/manager]=\
  INFO, MANAGER
log4j.logger.org.apache.catalina.core.ContainerBase.[Catalina].[localhost].[/host-manager]=\
  INFO, HOST-MANAGER
Download Log4J (v1.2 or later) and place the log4j jar in $CATALINA_HOME/lib.

Build or download the additional logging components. See the extras components documentation for details.

Replace $CATALINA_HOME/bin/tomcat-juli.jar with output/extras/tomcat-juli.jar.

Place output/extras/tomcat-juli-adapters.jar in $CATALINA_HOME/lib.

Delete $CATALINA_BASE/conf/logging.properties to prevent java.util.logging generating zero length log files.

Start Tomcat

This log4j configuration mirrors the default java.util.logging setup that ships with Tomcat: both the manager and host-manager apps get an individual log file, and everything else goes to the "catalina.log" log file. Each file is rolled-over once per day.

You can (and should) be more picky about which packages to include in the logging. Tomcat defines loggers by Engine and Host names. For example, for a more detailed 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.
log4j.logger.org.apache.catalina.core.ContainerBase.[Catalina].[localhost]=DEBUG
log4j.logger.org.apache.catalina.core=DEBUG
log4j.logger.org.apache.catalina.session=DEBUG
      
Be warned a level of DEBUG will produce megabytes of logging and slow startup of Tomcat. This level should be used sparingly when debugging of internal Tomcat operations is required.

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 directory, and log4jx.y.z.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.

If you have multiple instances of Tomcat, each with a separate $CATALINA_BASE but a shared $CATALINA_HOME then you can configure log4j on a per instance basis by replacing references to $CATALINA_HOME in the above instructions with $CATALINA_BASE. Note that if you do this then you may need to make some, or all, of the following additional changes:

create a $CATALINA_BASE/bin directory

create a $CATALINA_BASE/lib directory

if running with a security manager, adjust the codebase for JULI in $CATALINA_BASE/conf/catalina.policy