Jetty Logo
Contact the core Jetty developers at

private support for your internal/customer projects ... custom extensions and distributions ... versioned snapshots for indefinite support ... scalability guidance for your apps and Ajax/Comet projects ... development services from 1 day to full product delivery

Chapter 9. Jetty Logging

Table of Contents

Configuring Jetty Logging
Configuring Jetty Request Logs
Example: Logging with Apache Log4j
Example: Logging with Java's java.util.logging
Example: Logging with Logback
Example: Capturing Multiple Logging frameworks with Slf4j
Example: Centralized Logging with Logback

This chapter discusses various options for configuring logging.

Configuring Jetty Logging

Jetty provides logging via its own org.eclipse.jetty.util.log.Logger layer, and does not natively use any existing Java logging framework. All logging events, produced via the Jetty logging layer, have a name, a level, and a message. The name is a FQCN (fully qualified class name) similar to how all existing Java logging frameworks operate.

Jetty logging, however, has a slightly different set of levels that it uses internally:


For events serious enough to inform and log, but not fatal.


Informational events.


Debugging events (very noisy)


Exception events that you can safely ignore, but useful for some people. You might see this level as DEBUG under some Java logging framework configurations, where its retain the ignore phrase somewhere in the logging).


Jetty Logging produces no FATAL or SEVERE events.

Selecting the Log Framework

Configure the Jetty logging layer via the org.eclipse.jetty.util.log.Log class, following these rules.

  1. Load Properties

    • First from a Classpath Resource called (if found).

    • Then from the System.getProperties().

  2. Determine the Log implementation.

    • If property org.eclipse.jetty.util.log.class is defined, load the class it defines as the Logger implementation from the server classpath.

    • If the class org.slf4j.Logger exists in server classpath, the Jetty implementation becomes org.eclipse.jetty.util.log.Slf4jLog.

    • If no logger implementation is specified, default to org.eclipse.jetty.util.log.StdErrLog.


You can create your own custom logging by providing an implementation of the Jetty Logger API. For an example of a custom Logger, see

Configuring Jetty StdErrLog

If you select the default Jetty logger (StdErrLog), you can then use further properties (either as System properties or in a as outlined in Selecting the Log Framework) to control event levels to log and to adjust the format of those logs.

Table 9.1. Logging Parameters

Logging PropertyDescription
<name>.LEVEL=<level>Sets the logging level for all loggers within the name specified to the level, which can be (in increasing order of restriction) ALL, DEBUG, INFO, WARN, OFF. The name (or hierarchy) can be a specific fully qualified class or a package namespace, for example, -Dorg.eclipse.jetty.http.LEVEL=DEBUG is a package namespace approach to turn all loggers in the jetty HTTP package to DEBUG level, and turns on all logging events for the specific class, including DEBUG, INFO, WARN (and even special internally ignored exception classes). If more than one system property specifies a logging level, the most specific one applies.
<name>.SOURCE=<boolean>Logger specific, attempts to print the Java source file name and line number from where the logging event originated. Name must be a fully qualified class name (package name hierarchy is not supported by this configurable). Default is false. Be aware that this is a slow operation and has an impact on performance!
<name>.STACKS=<boolean>Logger specific, controls the display of stacktraces. Name must be a fully qualified class name (package name hierarchy is not supported by this configurable). Default is true.
org.eclipse.jetty.util.log.IGNORED=<boolean>If set to true, exceptions that have been recorded as ignored with the LOG.ignore(throwable) API are logged with a full stack trace. Otherwise ignored exceptions are either not logged, or logged in summary if the level is debug.
org.eclipse.jetty.util.log.stderr.SOURCE=<boolean>Special Global Configuration. Attempts to print the Java source file name and line number from where the logging event originated. Default is false.
org.eclipse.jetty.util.log.stderr.LONG=<boolean>Special Global Configuration. When true, outputs logging events to STDERR using long form, fully qualified class names. When false, uses abbreviated package names. Default is false.





These are deprecated properties from older Jetty versions that are now ignored with a warning if used.

Changing log level in resources/

# Set up logging implementation
# Make websocket more verbose for testing

This sets the Logging Implementation to StdErrLog.

Configures the logging level for "org.eclipse.jetty" to be INFO

Configures the logging level for "org.eclipse.jetty.websocket" to be DEBUG

Changing log level in etc/jetty.xml

<Call class="org.eclipse.jetty.util.log.Log" name="getRootLogger">
  <Call name="setDebugEnabled">
    <Arg type="boolean">true</Arg>

This technique, from older versions of Jetty, is used to configure all of the StdErrLog loggers (no other implementations support this) to be logging at DEBUG level.

Using etc/jetty-logging.xml

You can use etc/jetty-logging.xml to take all System.out and System.err output (from any source) and route it to a rolling log file. To do so, include etc/jetty-logging.xml on Jetty startup.

$ java -jar start.jar etc/jetty-logging.xml      

See an error or something missing? Contribute to this documentation at Github!