Configuring Apache Tomcat Logs

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:

q  Use any logging framework of its choice

q  Use system logging API, java.util.logging

q  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 the 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.

Servlets Logging APICalls 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. Whatever is written to System.err/out  will be caught into that file. That may include:

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

q  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 swallowOutputattribute 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.