Jetty Logo
Version: 9.2.2-SNAPSHOT
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

Example: Centralized Logging with Logback

The term Centralized Logging refers to a forced logging configuration for the Jetty Server and all web applications that are deployed on the server. It routes all logging events from the web applications to a single configuration on the Server side.

The example below shows how to accomplish this with Jetty and Slf4j, using Logback to manage the final writing of logs to disk.


This mechanism forces all webapps to use the server's configuration for logging, something that isn't 100% appropriate for all webapps.

An example would be having Jenkins-CI deployed as an webapp, if you force its logging configuration to the server side, you lose the ability on Jenkins-CI to see the logs from the various builds (as now those logs are actually going to the main server log)

This configuration is essentially the multiple logger configuration with added configuration to the deployers to force a WebAppClassLoader change to use the server classpath over the webapps classpath for the logger specific classes.

The technique used by this configuration is to provide an AppLifeCycle.Binding against the "deploying" node that modifies the WebAppContext.addSystemClass(String) for the common logging classes. (See org.eclipse.jetty.logging.CentralizedWebAppLoggingBinding for actual implementation)

Quick Setup of Centralized Logging using Jetty 9.2.1+

A convenient replacement logging module has been created to bootstrap your ${jetty.base} directory for capturing all Jetty server logging from multiple logging frameworks into a single logging output file managed by logback.

[mybase]$ mkdir modules
[mybase]$ cd modules

[modules]$ curl -O
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100  1416  100  1416    0     0   4241      0 --:--:-- --:--:-- --:--:--  4252

[master]$ curl -O
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100   660  100   660    0     0   2032      0 --:--:-- --:--:-- --:--:--  2037
[modules]$ cd ..

[mybase]$ java -jar /opt/jetty-dist/start.jar --add-to-start=logging,webapp-logging
INFO: logging         initialised in ${jetty.base}/start.ini (appended)
MKDIR: ${jetty.base}/logs
DOWNLOAD: to lib/logging/slf4j-api-1.6.6.jar
DOWNLOAD: to lib/logging/log4j-over-slf4j-1.6.6.jar
DOWNLOAD: to lib/logging/jul-to-slf4j-1.6.6.jar
DOWNLOAD: to lib/logging/jcl-over-slf4j-1.6.6.jar
DOWNLOAD: to lib/logging/logback-core-1.0.7.jar
DOWNLOAD: to lib/logging/logback-classic-1.0.7.jar
DOWNLOAD: to resources/logback.xml
DOWNLOAD: to resources/
DOWNLOAD: to etc/jetty-logging.xml
INFO: resources       initialised transitively
INFO: resources       enabled in     ${jetty.base}/start.ini
INFO: webapp-logging  initialised in ${jetty.base}/start.ini (appended)
DOWNLOAD: to lib/webapp-logging/jetty-webapp-logging-9.0.0.jar
DOWNLOAD: to etc/jetty-webapp-logging.xml
DOWNLOAD: to etc/jetty-mdc-handler.xml
INFO: deploy          initialised transitively
INFO: deploy          enabled in     ${jetty.base}/start.ini
INFO: logging         initialised transitively
INFO: resources       initialised transitively
INFO: resources       enabled in     ${jetty.base}/start.ini

[mybase]$ java -jar /opt/jetty-dist/start.jar

That's cool and all, but tell me what that just did.

The replacement logging.mod performs a number of tasks.

  1. mybase is a ${jetty.base} directory

  2. The jetty-distribution is unpacked (and untouched) into /opt/jetty-dist/ and becomes the ${jetty.home} directory for this demonstration.

  3. The curl command downloads the replacement logging.mod and puts it into the ${jetty.base}/modules/ directory for use by mybase only.

  4. The start.jar --add-to-start=logging,webapp-logging command performs a number of steps to make the logging module available to the ${jetty.base} configuration.

    1. Several entries are added to the ${jetty.base}/start.ini configuration

      1. --module=logging is added to enable the logging module

      2. --module=webapp-logging is added to enable the webapp-logging module

    2. Required ${jetty.base} directories are created: ${jetty.base}/logs and ${jetty.base}/resources

    3. Required logging libraries are downloaded (if not present already):

      • slf4j-api.jar - API jar for Slf4j (used by most of the rest of the jars)

      • log4j-over-slf4j.jar - Slf4j jar that captures all log4j emitted logging events

      • jul-to-slf4j.jar - Slf4j jar that captures all java.util.logging events

      • jcl-over-slf4j.jar - Slf4j jar that captures all commons-logging events

      • logback-classic.jar - the Slf4j adapter jar that routes all of the captured logging events to logback itself.

      • logback-core.jar - the logback implementation jar, that handles all of the filtering and output of the logging events.

      These libraries are put in the ${jetty.base}/lib/logging/ directory.

    4. Required webapp-logging library are downloaded (if not present already):

      • jetty-webapp-logging.jar - the jetty side deployment manger app-lifecycle bindings for modifying the WebAppClassloaders of deployed webapps.

      This library is put in the ${jetty.base}/lib/webapp-logging/ directory.

    5. Required configuration files are downloaded (if not present already):, and logback.xml

      The configuration files are put in the ${jetty.base}/resources/ directory.

    6. Required initialization commands are downloaded (if not present already): jetty-logging.xml, jetty-webapp-logging.xml, and jetty-mdc-handler.xml

      These xml files are put in the ${jetty.base}/etc/ directory.

  5. At this point you have your mybase configured so that the jetty server itself will log using slf4j, and all other logging events from other Jetty Server components (such as database drivers, security layers, jsp, mail, and other 3rd party server components) are routed to logback for filtering and output.

    All webapps deployed via the DeploymentManager have their WebAppClassLoader modified to use server side classes and configuration for all logging implementations.

You can verify the server classpath by using the start.jar --list-config command.

In essence, Jetty is now configured to emit its own logging events to slf4j, and various slf4j bridge jars are acting on behalf of log4j, java.util.logging, and commons-logging, routing all of the logging events to logback (a slf4j adapter) for routing (to console, file, etc...)

See an error or something missing? Contribute to this documentation at Github!(Generated: 2014-08-27T01:00:25-07:00)