Links User Guide Reference Apache Tomcat Development | Logging in Tomcat| Introduction |
Logging in Apache Tomcat is implemented with the help of
Apache Commons Logging
library. That library is a thin wrapper above different logging
frameworks. It provides Tomcat with the ability to log
hierarchically across various log levels without the need to rely on a
particular logging implementation.
Since Tomcat 6.0, Tomcat uses a private package-renamed implementation of
Apache Commons Logging, to allow web applications to use their own
independent copies of the original Apache Commons Logging library.
In the default distribution this private copy of the library
is simplified and hardcoded to use the java.util.logging framework.
To configure Tomcat to use alternative logging frameworks for its internal
logging, one has to replace the logging library with the one that is built
with the full implementation. Such library 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 system logging API,
java.util.logging.
-
Use the logging API provided by the Java Servlets specification,
javax.servlet.ServletContext.log(...)
-
Use any logging framework of its choice.
The logging frameworks used by different web applications run independently
of each other. 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. That is because it is loaded
by the system and is shared across web applications.
| 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.
|
| 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 |
A related, but different feature is access logging. It can be configured
as a valve at the Context, or Host, or Engine. See Valves
documentation for more details.
|
|
| Using java.util.logging (default) |
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:
- Globally. That is usually done in the
${catalina.base}/conf/logging.properties file.
The file is specified by the java.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 FileHandlers 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.
Here is how you would set debugging from Tomcat. You would need to ensure the
ConsoleHandler's (or FileHandler's') level is also set to collect this threshold,
so FINEST or ALL should be set. Please refer to java.util.logging
documentation in the JDK for the complete details:
 | | | | org.apache.catalina.level=FINEST | | | | |
The configuration used by JULI is extremely similar to the one supported by
plain java.util.logging, 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.
- System property replacement is performed for property values which
contain ${systemPropertyName}.
- As in Java 6, 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 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
| | |
|
|
