Apache Tomcat 6.0 - Logging in Tomcat
Author: Allistair Crossley

| # Apache Tomcat 6.0 |

Links Docs Home FAQ User Guide 1) Introduction 2) Setup 3) First webapp 4) Deployer 5) Manager 6) Realms and AAA 7) Security Manager 8) JNDI Resources 9) JDBC DataSources 10) Classloading 11) JSPs 12) SSL 13) SSI 14) CGI 15) Proxy Support 16) MBean Descriptor 17) Default Servlet 18) Clustering 19) Load Balancer 20) Connectors 21) Monitoring and Management 22) Logging 23) APR/Native 24) Virtual Hosting 25) Advanced IO 26) Additional Components 27) Mavenized Reference Release Notes Configuration Javadocs JK 1.2 Documentation Apache Tomcat Development Building Changelog Status Developers Architecture Functional Specs. | # Apache Tomcat 6.0 ## Logging in Tomcat
Table of Contents
Introduction java.util.logging log4j
Introduction
Tomcat 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 with the ability to log hierarchically across various log levels without needing to rely on a particular logging implementation. By default, only java.util.logging is available for the logs generated by the Tomcat internal loggers, as Tomcat uses a package renamed commons logging implementation which is hardcoded to use java.util.logging. Use of alternative logging frameworks requires building or downloading the extras components which include a full commons-logging implementation. Instructions for configuring the extras components to enable log4j to be used for Tomcat's internal logging may be found below. Tomcat no longer uses `localhost_log` 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.
java.util.logging
> 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 com.xyz.foo logger to only log SEVERE
>     # messages:
>     #org.apache.catalina.startup.ContextConfig.level = FINE
>     #org.apache.catalina.startup.HostConfig.level = FINE
>     #org.apache.catalina.session.ManagerBase.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
log4j
> 1. 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, R
>        log4j.appender.R=org.apache.log4j.RollingFileAppender
>        log4j.appender.R.File=${catalina.base}/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
> 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 sets up a file called tomcat.log in your Tomcat logs folder with a maximum file size of 10MB and up to 10 backups. INFO level is specified which will result in a similar level of detail to the standard java.util.logging confgiuration. Use DEBUG level logging for the most verbose output from Tomcat. 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_HOME` but a shared `$CATALINA_BASE`, 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 you may need to create a `$CATALINA_BASE/lib` directory.
Copyright © 1999-2010, Apache Software Foundation