Logging in Tomcat
Table of Contents
Introduction
      The internal logging for Apache Tomcat uses JULI, a packaged renamed fork
      of Apache Commons Logging
      that 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, follow the instructions provided by the alternative
      logging framework for redirecting logging for applications that use
      java.util.logging. Keep in mind that the alternative logging
      framework will need to be capable of working in an environment where
      different loggers with the same name may exist in different class loaders.
    
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 is
      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 SEVERE 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.propertiesfile. The file is specified by thejava.util.logging.config.fileSystem 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.propertiesfile 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 AsyncFileHandlers 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=ALLWhen 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.WebappPropertiesinterface (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.useParentHandlersproperty, which accepts a boolean value.
- The root logger can define its set of handlers using the
      .handlersproperty.
-  By default the log files will be kept on the file system forever.
      This may be changed per handler using the
      handlerName.maxDaysproperty. If the specified value for the property is≤0then the log files will be kept on the file system forever, otherwise they will be kept the specified maximum days.
    There are several additional implementation classes, that can be used
    together with the ones provided by Java. The notable ones are
    org.apache.juli.FileHandler and org.apache.juli.AsyncFileHandler.
  
    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.
  
    org.apache.juli.AsyncFileHandler is a subclass of FileHandler
      that queues the log messages and writes them asynchronously to the log files.
      Its additional behaviour can be configured by setting some
      system properties.
  
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.
1catalina.org.apache.juli.FileHandler.maxDays = 90
1catalina.org.apache.juli.FileHandler.encoding = UTF-8
2localhost.org.apache.juli.FileHandler.level = FINE
2localhost.org.apache.juli.FileHandler.directory = ${catalina.base}/logs
2localhost.org.apache.juli.FileHandler.prefix = localhost.
2localhost.org.apache.juli.FileHandler.maxDays = 90
2localhost.org.apache.juli.FileHandler.encoding = UTF-8
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
3manager.org.apache.juli.FileHandler.maxDays = 90
3manager.org.apache.juli.FileHandler.encoding = UTF-8
java.util.logging.ConsoleHandler.level = FINE
java.util.logging.ConsoleHandler.formatter = java.util.logging.OneLineFormatter
java.util.logging.ConsoleHandler.encoding = UTF-8
############################################################
# 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 = FINEExample 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.OneLineFormatterDocumentation references
See the following resources for additional information:
- Apache Tomcat Javadoc for the
          org.apache.julipackage.
- Oracle Java 7 Javadoc for the
          java.util.loggingpackage.
Considerations for production usage
You may want to take note of the following:
- Consider removing ConsoleHandlerfrom configuration. By default (thanks to the.handlerssetting) logging goes both to aFileHandlerand 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 FileHandlers 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 encodingproperty. See Javadoc for details.
- Consider configuring an Access log.
