Logging in Tomcat
Table of Contents
Introduction
The internal logging for Apache Tomcat uses JULI, a packaged renamed fork
of Apache Commons Logging
that, by default, is hard-coded to use the java.util.logging
framework. This ensures that Tomcat's internal logging and any web
application logging will remain independent, even if a web application
uses Apache Commons Logging.
To configure Tomcat to use an alternative logging framework for its
internal logging, one has to replace the JULI implementation that is
hard-coded to use java.util.logging
with a JULI
implementation that retains the full Commons Logging discovery mechanism.
Such an implementation 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 any logging framework of its choice.
-
Use system logging API,
java.util.logging
. -
Use the logging API provided by the Java Servlets specification,
javax.servlet.ServletContext.log(...)
The logging frameworks used by different web applications are independent.
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 then elements of it will be
shared across web applications because it is loaded by the system class
loader.
Java logging API — java.util.logging
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 java.util.logging may be found in the documentation
for your JDK and on its Javadoc pages for the java.util.logging
package.
More details about Tomcat JULI may be found below.
Servlets logging API
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.
The Servlets logging API predates the java.util.logging
API
that is now provided by Java. As such, it does not offer you much options.
E.g., you cannot control the log levels. It can be noted, though, that
in Apache Tomcat implementation the calls to ServletContext.log(String)
or GenericServlet.log(String)
are logged at the INFO level.
The calls to ServletContext.log(String, Throwable)
or
GenericServlet.log(String, Throwable)
are logged at the ERROR level.
Console
When running Tomcat on unixes, the console output is usually redirected
to the 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 caught into
that file. That may include:
- Uncaught exceptions printed by
java.lang.ThreadGroup.uncaughtException(..)
- Thread dumps, if you requested them via a system signal
When running as a service on Windows, the console output is also caught and redirected, but the file names are different.
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.
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
, the 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 the swallowOutput
feature is
actually a trick, and it has its limitations.
It works only with direct calls to System.out/err
,
and only during request processing cycle. It may not work in other
threads that might be created by the application. 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
before the redirection takes place.
Access logging
Access logging is a related but different feature, which is
implemented as a Valve
. It uses self-contained
logic to write its log files. The essential requirement for
access logging is to handle a large continuous stream of data
with low overhead, so it only uses Apache Commons Logging for
its own debug messages. This implementation approach avoids
additional overhead and potentially complex configuration.
Please refer to the Valves
documentation for more details on its configuration, including
the various report formats.
Using java.util.logging (default)
The default implementation of java.util.logging provided in the JDK is too limited to be useful. The key limitation is 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.
JULI 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 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:
- Globally. That is usually done in the
${catalina.base}/conf/logging.properties
file. The file is specified by thejava.util.logging.config.file
System property which is set by the startup scripts. If it is not readable or is not configured, the default is to use the${java.home}/lib/logging.properties
file in the JRE. - In the web application. The file will be
WEB-INF/classes/logging.properties
The default logging.properties
in the JRE specifies a
ConsoleHandler
that routes logging to System.err.
The default conf/logging.properties
in Apache Tomcat also
adds several FileHandler
s that write to files.
A handler's log level threshold is INFO by default and can be set using SEVERE, WARNING, INFO, CONFIG, FINE, FINER, FINEST or ALL. You can also target specific packages to collect logging from and specify a level.
To enable debug logging for part of Tomcat's internals, you should
configure both the appropriate logger(s) and the appropriate handler(s) to
use the FINEST
or ALL
level. e.g.:
org.apache.catalina.session.level=ALL
java.util.logging.ConsoleHandler.level=ALL
When enabling debug logging it is recommended that it is enabled for the narrowest possible scope as debug logging can generate large amounts of information.
The configuration used by JULI is the same as the one supported by plain
java.util.logging
, but uses a few extensions to allow better
flexibility in configuring loggers and handlers. 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. - System property replacement is performed for property values which contain ${systemPropertyName}.
- If using a class loader that implements the
org.apache.juli.WebappProperties
interface (Tomcat's web application class loader does) then property replacement is also performed for${classloader.webappName}
,${classloader.hostName}
and${classloader.serviceName}
which are replaced with the web application name, the host name and the service name respectively. - 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 the
.handlers
property.
There are several additional implementation classes, that can be used
together with the ones provided by Java. The notable one is
org.apache.juli.FileHandler
.
org.apache.juli.FileHandler
supports buffering of the
logs. The buffering is not enabled by default. To configure it, use the
bufferSize
property of a handler. The 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.
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, \
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.
3manager.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
# 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 = ${classloader.webappName}.
java.util.logging.ConsoleHandler.level = FINE
java.util.logging.ConsoleHandler.formatter = java.util.logging.SimpleFormatter
Documentation references
See the following resources for additional information:
- Apache Tomcat Javadoc for the
org.apache.juli
package. - Oracle Java 6 Javadoc for the
java.util.logging
package.
Considerations for production usage
You may want to take note of the following:
- Consider removing
ConsoleHandler
from configuration. By default (thanks to the.handlers
setting) logging goes both to aFileHandler
and to aConsoleHandler
. The output of the latter one is usually captured into a file, such ascatalina.out
. Thus you end up with two copies of the same messages. - Consider removing
FileHandler
s for the applications that you do not use. E.g., the one forhost-manager
. - The handlers by default use the system default encoding to write
the log files. It can be configured with
encoding
property. See Javadoc for details. - Consider configuring an Access log.
Using Log4j
This section explains how to configure Tomcat to use log4j rather than java.util.logging for all Tomcat's internal logging.
Note: The steps described in this section are needed
when you want to reconfigure Tomcat to use Apache log4j for its own
logging. These steps are not needed if you just want
to use log4j in your own web application. — In that case, just
put log4j.jar
and log4j.properties
into
WEB-INF/lib
and WEB-INF/classes
of your web application.
The following steps describe configuring log4j to output Tomcat's internal logging.
- Create a file called
log4j.properties
with the following content and save it into$CATALINA_BASE/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.Append = true
log4j.appender.CATALINA.Encoding = UTF-8
# Roll-over the log once per day
log4j.appender.CATALINA.DatePattern = '.'yyyy-MM-dd'.log'
log4j.appender.CATALINA.layout = org.apache.log4j.PatternLayout
log4j.appender.CATALINA.layout.ConversionPattern = %d [%t] %-5p %c- %m%n
log4j.appender.LOCALHOST = org.apache.log4j.DailyRollingFileAppender
log4j.appender.LOCALHOST.File = ${catalina.base}/logs/localhost
log4j.appender.LOCALHOST.Append = true
log4j.appender.LOCALHOST.Encoding = UTF-8
log4j.appender.LOCALHOST.DatePattern = '.'yyyy-MM-dd'.log'
log4j.appender.LOCALHOST.layout = org.apache.log4j.PatternLayout
log4j.appender.LOCALHOST.layout.ConversionPattern = %d [%t] %-5p %c- %m%n
log4j.appender.MANAGER = org.apache.log4j.DailyRollingFileAppender
log4j.appender.MANAGER.File = ${catalina.base}/logs/manager
log4j.appender.MANAGER.Append = true
log4j.appender.MANAGER.Encoding = UTF-8
log4j.appender.MANAGER.DatePattern = '.'yyyy-MM-dd'.log'
log4j.appender.MANAGER.layout = org.apache.log4j.PatternLayout
log4j.appender.MANAGER.layout.ConversionPattern = %d [%t] %-5p %c- %m%n
log4j.appender.HOST-MANAGER = org.apache.log4j.DailyRollingFileAppender
log4j.appender.HOST-MANAGER.File = ${catalina.base}/logs/host-manager
log4j.appender.HOST-MANAGER.Append = true
log4j.appender.HOST-MANAGER.Encoding = UTF-8
log4j.appender.HOST-MANAGER.DatePattern = '.'yyyy-MM-dd'.log'
log4j.appender.HOST-MANAGER.layout = org.apache.log4j.PatternLayout
log4j.appender.HOST-MANAGER.layout.ConversionPattern = %d [%t] %-5p %c- %m%n
log4j.appender.CONSOLE = org.apache.log4j.ConsoleAppender
log4j.appender.CONSOLE.Encoding = UTF-8
log4j.appender.CONSOLE.layout = org.apache.log4j.PatternLayout
log4j.appender.CONSOLE.layout.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 (Tomcat requires v1.2.x).
Download or build
tomcat-juli.jar
andtomcat-juli-adapters.jar
that are available as an "extras" component for Tomcat. See Additional Components documentation for details.This
tomcat-juli.jar
differs from the default one. It contains the full Apache Commons Logging implementation and thus is able to discover the presence of log4j and configure itself.If you want to configure Tomcat to use log4j globally:
- Put
log4j.jar
andtomcat-juli-adapters.jar
from "extras" into$CATALINA_HOME/lib
. - Replace
$CATALINA_HOME/bin/tomcat-juli.jar
withtomcat-juli.jar
from "extras".
- Put
If you are running Tomcat with separate
$CATALINA_HOME
and$CATALINA_BASE
and want to configure to use log4j in a single$CATALINA_BASE
only:- Create
$CATALINA_BASE/bin
and$CATALINA_BASE/lib
directories if they do not exist. - Put
log4j.jar
andtomcat-juli-adapters.jar
from "extras" into$CATALINA_BASE/lib
- Put
tomcat-juli.jar
from "extras" as$CATALINA_BASE/bin/tomcat-juli.jar
- If you are running with a
security manager, you
would need to edit the
$CATALINA_BASE/conf/catalina.policy
file to adjust it to using a different copy of tomcat-juli.jar.
Note: This works because libraries, if they exist in
$CATALINA_BASE
, are loaded in preference to the same library in$CATALINA_HOME
.Note: tomcat-juli.jar is loaded from
$CATALINA_BASE
/bin not$CATALINA_BASE
/lib as it is loaded as part of the bootstrap process and all the bootstrap classes are loaded from bin.- Create
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.
Additional notes
This exposes log4j libraries to the web applications through the Common classloader. See class loading documentation for details.
Because of that, the web applications and libraries using Apache Commons Logging library are likely to automatically choose log4j as the underlying logging implementation.
The
java.util.logging
API is still available for those web applications that use it directly. The${catalina.base}/conf/logging.properties
file is still referenced by Tomcat startup scripts. For more information, see the subsections of the Introduction to this page.Removal of
${catalina.base}/conf/logging.properties
file, mentioned as one of the steps above, causesjava.util.logging
to fallback to the default configuration for the JRE, which is to use a ConsoleHandler and therefore not create any standard log files. You should confirm that all your log files are being created by log4j before disabling the standard mechanism.The Access Log Valve and ExtendedAccessLogValve use their own self-contained logging implementation, so they cannot be configured to use log4j. Refer to Valves for specific configuration details.