Jetty has moved!
Jetty is a project at the Eclipse Foundation.
Jetty Powered:
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
Skip to end of metadata
Go to start of metadata


Quick Start

Jetty has it's own builtin logging facade that can log to stderr or slf4j (which in turn can log to commons logging, log4j, nlog4j and java logging).

Jetty logging looks for a slf4j jar on the classpath. If found, slf4j is used to control logging otherwise stderr is used. The org.mortbay.log.Log class is used to coordinate logging and the following system parameters may be used to control logging:


Specify an implementation of org.mortbay.log.Logger to use


If set, debug logs will be produced, else only INFO and WARN logs will be generated


If set, verbose logging is produced, including ignored exceptions


If set (jetty 6.1.10 and later), ignored exceptions are logged (independent of DEBUG and VERBOSE settings

With Jetty Standalone

The core of Jetty has no hard dependencies on an external logging infrastructure. The only logging dependency is introduced by Jasper, the JSP engine.

Jasper has traditionally had a dependency on commons-logging, which proves problematic in container-based architectures. To overcome this, Jetty uses 2 different solutions, depending on the version of JSP standard.

Note that the start.jar mechanism will automatically select a JSP version for you at runtime based on the jdk version. As JSP2.1 mandates at least jdk1.5, if you are running with a 1.5 jvm then this will be the version selected. However, if you are running with a lower version jvm, the start.jar mechanism will place the JSP2.0 jars onto the classpath.


Jetty uses the SLF4J logging infrastructure to bridge to commons-logging for JSP2.0. This means that commons-log messages are sent to the SLF4J interface.

We ship the Simple log implementation, which will only output INFO level and above messages to stderr.

However, you can replace the Simple log with any other SLF4J log implementation by removing the lib/jsp-2.0/slf4j-simple-1.0-rc5.jar and copying in the SLF4J impl of your choice. The core Jetty code has a soft dependency on SLF4J, meaning that if an SLF4J impl is found on the classpath at startup Jetty will direct all logging messages to it.

Alternatively, you can remove the SLF4J jars altogether and use commons-logging instead by copying in the commons-logging jar and a commons-logging compliant log impl, such as log4j, to the lib/ directory. However, if you do that, be aware that as the core Jetty code does not use commons-logging, it will log messages to stderr instead. Read on to learn how to get the stderr log mechanism to print DEBUG level messages.


With the newest version of the JSP specification, Jetty has removed all logging dependencies from the Jasper code. This means that no external logger is needed and Jetty uses it's own stderr logging mechanism. By default, that will only output INFO level and above messages.

To enable logging of DEBUG level messages, invoke Jetty with the -DDEBUG flag:

With Jetty embedded

As mentioned above, the core of Jetty has no hard external logging dependency. Therefore, if you only include the lib/jetty-util.jar and lib/jetty.jar on your classpath, Jetty will direct all log messages to stderr. To see DEBUG level messages, start your application with the -DDEBUG flag:

Or alternatively call SystemProperty.set("DEBUG", "true") before calling new org.mortbay.jetty.Server().

If your embedded application includes the jars from either of the JSP versions in lib/, then read the previous section for instructions on how to configure logging.

With the Jetty Maven2 Plugin

As with all Maven plugins, log messages produced by the plugin itself will be sent to stderr and only at the INFO level and above. To see DEBUG level messages from the plugin, invoke the plugin with the -X flag:

Log messages from the Jetty instance embedded in the plugin are controlled in much the same way as Jetty standalone. The plugin picks an appropriate JSP version based on the version of the jvm executing the plugin. Please see the Jetty Maven2 Plugin pages for an explanation of how to configure logging.

  • No labels


  1. I had lots of trouble figuring out how to control all logging in Jetty 6. The following worked for me:

    // Configure Jetty logging to a more reasonable default.
    System.setProperty("org.mortbay.log.class", "com.example.JettyLog");
    // JSP 2.0 uses commons-logging, so also override that implementation.

    Obviously, replace "JettyLog" and "CommonsLogFactory" with your own classes. JettyLog should implement org.mortbay.log.Logger and "CommonsLogFactory" should extend org.apache.commons.logging.LogFactory

    In your custom classes you can disable all INFO logging, send it to specific places, etc. There may be more elegant ways of doing this, but the above worked! 

  2. Matt, jetty uses an slf4j implementation if it finds slf4j on the classpath. If none of the existing slf4j implementations float your boat, you could always write your own impl and simply make sure you put it in a jar in $jetty.home/lib and jetty would use it. Via the jcl104-over-slf4j, you would also
    ensure that all clogging calls were also directed to your custom impl.

  3. Running/Debugging Jetty with IntelliJ IDEA

    In order to integrate Jetty with, IntelliJ IDEA, you,need two scripts.

    1. StartJetty.bat

    2. StopJetty.bat

    These scripts are not named specifically as IntelliJ scripts because they are also general purpose batch files to start and stop and Jetty.

    The script works reliably when placed immediately in Jetty dir. The script uses JAVA_HOME environment variable if set. If it,is not set, then the script tries to determine JAVA_HOME from Windows Registry. The script can be run from any location, however the relative paths are computed with respect to Jetty dir. If you are running script from other dir then you should say 'Y' if prompted for "Terminate batch job (Y/N)?". This,situation frequently arise when Ctrl+C is used for terminating a batch program. Otherwise, you will notice that your current directory is still set to Jetty dir. This is generally, a good practice for other Batch programs as well.

    IntelliJ Configuration

    First of all, you would need to setup Jetty as Application Server in IntelliJ Settings. It's usually Ctrl+Alt+S or File->Settings. Navigate to "Application Servers" option,and add a Generic Server.

    It is,named,Jetty here and servlet-api-2.5.jar and other jars from,jetty lib dir are attached. You will also notice IntelliJ warning regarding not finding EJB classes. That's ok because Jetty is not an EJB container.

    To Debug and Run your web app project from IntelliJ, you need to create a Local "JSR45 Compatible Server" configuration under Run-> Edit Configurations menu. Note that IntelliJ only allows you to configure this for each project.

    I named the Local configuration as "Jetty".
    In "Server" tab, select Application Server we just created. Configure port consistent with jetty.xml,or value of jetty.port system property. Specify JSP package as org.apache.jsp. Refer to you webdefault.xml if you have,customized package for JSP generated java classes. Set value of VM options variable VM_DEBUG_VAR. This environment variable is used in Batch Scripts. Note: Due to certain bug in IntelliJ plugin,,if you name,this variable VM_OPTS, it is not passed to Batch Scripts. So avoid using VM_OPTS name,as environment variable. It's quite easy to use this variable as it is used in IntelliJ examples.
    You can also check/uncheck Start Browser,depending on what you want.

    In "Startup/Connection" tab,,you need to select the start and stop script for,running and debugging script.

    I have also specified JAVA_HOME environment variable in this case. The StartJetty.bat and StopJetty.bat script work for both running and debugging.
    IntelliJ passes,debug parameters in form of an environment variable to the script. See the value of VM_DEBUG_VAR created by IntelliJ for Debug mode.

    Other VM parameters and program arguments can be passed by selecting icon next to each script.

    Now create a jsp in your web app and try a breakpoint in a jsp.

    Jetty with,Java Service Wrapper by Tanuki Software

    Another approach,of running and,debugging is using,Java Service Wrapper itself in console mode using -c option. The advantage of using Java Service using is that you don't have to specify JVM options and program arguments in multiple places. For debugging purpose, you can simply add one of the following two options in your Java Service Wrapper conf file.

    Run Jetty in console mode., You only need conf file. You don't have to install this as Windows Service.

    Now you can use IntelliJ Remote debugging facility. See Remote tab under Run-> Edit Configurations menu option.

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