Apache Tomcat has its own implementation of several key elements of 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 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 package.

More details about Tomcat JULI may be found below.

The calls to to write log messages are handled by internal Tomcat logging. Such messages are logged to the category named

This logging is performed according to the Tomcat logging configuration. You cannot overwrite it in a web application.

The Servlets logging API predates the 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 or are logged at the INFO level. The calls to or are logged at the SEVERE level.

When running Tomcat on unixes, the console output is usually redirected to the file named . The name is configurable using an environment variable. (See the startup scripts). Whatever is written to will be caught into that file. That may include:

• Uncaught exceptions printed by
• 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 or can be tricked by setting attribute on a Context. If the attribute is set to , the calls to during request processing will be intercepted, and their output will be fed to the logging subsystem using the calls.
Note, that the feature is actually a trick, and it has its limitations. It works only with direct calls to , 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 is a related but different feature, which is implemented as a . 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.