Jetty Server

Jetty’s default SLF4J binding uses an appender (org.eclipse.jetty.logging.StdErrAppender) to format a logging message with metadata (like a timestamp) before sending it to System.err. The default StdErrAppender format is:

where <datetime> is a timestamp with the format yyyy-MM-dd HH:mm:ss.SSS.

You can configure the appender via a file named jetty-logging.properties, which must be found in the server class-path. When you enable the logging-jetty module — either directly or by transitive dependency, as in the following example — Jetty automatically generates a jetty-logging.properties file in $JETTY_BASE/resources/:

You can specify the following configuration options in jetty-logging.properties:

When using the Jetty SLF4J binding, the logging levels can be dynamically changed via JMX, see the troubleshooting section for more information.

Logging to System.err may be fine at development time, but you will typically want to capture logs on disk for later inspection, or if you don’t have a terminal access (for example, if you started Jetty as a service).

The console-capture Jetty module allows you to capture what is written to System.out and System.err and write it to a log file. By default, console-capture logs to a file in the $JETTY_BASE/logs/ directory.

See the console-capture module documentation for details on configuring how logs are written to the log directory.

You can use a different SLF4J binding if you are more familiar with other logging libraries, or if you need custom logging appenders. There are a number of out-of-the-box Jetty modules that you can use:

To enable the logging-logback module, run:

Since LogBack is released under a license that is different from Jetty’s, you will be prompted to accept the LogBack license. Once you accept the LogBack license, your $JETTY_BASE directory will have the following structure.

Jetty downloaded the required LogBack *.jar files, and created a $JETTY_BASE/resources/logback.xml file for configuring your LogBack logging. Please refer to the LogBack configuration manual for more information about how to configure LogBack.

To enable the logging-log4j2 module, run:

After accepting the Log4j2 license, you will have the following directory structure:

Jetty downloaded the required Log4j2 *.jar files, and created a $JETTY_BASE/resources/log4j2.xml file that you can configure to customize your Log4j2 logging.

Please refer to the Log4j2 configuration manual for more information about how to configure Log4j2.

When you use libraries that provide the features you need (for example, JDBC drivers), it may be possible that those libraries use a different logging framework than SLF4J.

SLF4J provides bridges for legacy logging APIs that allows you to bridge logging from one of these legacy logging frameworks to SLF4J. Once the logging is bridged to SLF4J, you can use Jetty’s default configuration or a custom configuration so that your logging is centralized in one place.

Jetty provides the logging-jul-capture module for bridging from java.util.logging to SLF4J.

For libraries that use java.util.logging as their logging framework, you can enable Jetty’s logging-jul-capture module:

The logging-jul-capture module implies --exec and therefore spawns a second JVM because it needs to provide the system property java.util.logging.config.file (so that java.util.logging can read the configuration from the specified file), and because it needs to make available on the System ClassLoader the class org.slf4j.bridge.SLF4JBridgeHandler.

For example, a library that uses java.util.logging as its logging library is the Postgresql JDBC driver. With the logging-jul-capture Jetty module, the logging follows this diagram:

Note how Jetty logs directly to SLF4J, while the Postgresql JDBC driver logs to SLF4J through the SLF4JBridgeHandler. They both arrive to the SLF4J binding, in this case the Jetty SLF4J binding (but could be any other SLF4J binding such as LogBack).