A sample webapp+servlet that accepts arbitrary values on a form POST and logs them via Slf4J, so that you can see the results of this example.

Details

Configuring Basic Logback for Jetty

ImportantSee the /jetty-distro-with-logback-basic/ for a Maven project that builds this configuration. Notice that the output directory /jetty-distro-with-logback-basic/target/jetty-distro/ is where Maven builds it.

To configure basic logback for Jetty:

Unpack your Jetty 7.x Distribution Zip of choice The example uses the latest stable release (7.4.5.v20110725 at the time of writing).

Jetty configured to use slf4j (via the existance slf4j-api.jar in the classpath on Jetty startup)

slf4j configured to use logback (via the existance of logback-core.jar in the classpath at Jetty startup)

logback configured to produce output to:

${jetty.home}/logs/jetty.log (with daily rolling)

and STDOUT console

Pretty easy huh?

Go ahead and start Jetty.

$ java -jar start.jar

You’ll notice that the log events being produced by Jetty are being handled by Slf4j and Logback is doing the writing of those events to the STDOUT console and logs/jetty.log file

Now lets try something a bit more complex.

Sifting Logs produced by webapps via Hostname using Logback in Jetty

Lets say we have several virtual hosts, or a variety of DNS hostnames for the Jetty instance that is running.And you want to have the logging events being produced by the webapps captured into uniquely named log files by the hostname that the request came in on.

This too is possible with logback, albeit with a little help from slf4j and jettty WebappContextClassloader configuration.

See the /jetty-distro-with-logback-sifting/ project example from the github project above for a build-able configuration of the following instructions:

Unpack your Jetty 7.x Distribution Zip of choice. The example uses the latest stable release. (7.4.5.v20110725 at the time of writing this)

Configure ${jetty.home}/start.ini to add the lib/logging directory into the server classpath #===========================================================
# Start classpath OPTIONS.
# These control what classes are on the classpath
# for a full listing do
# java -jar start.jar --list-options
#-----------------------------------------------------------
OPTIONS=Server,resources,logging,websocket,ext
#-----------------------------------------------------------
#===========================================================
# Configuration files.
# For a full list of available configuration files do
# java -jar start.jar --help
#-----------------------------------------------------------
etc/jetty.xml
# etc/jetty-requestlog.xml

etc/jetty-mdc-handler.xml
etc/jetty-deploy.xml
etc/jetty-webapps.xml
etc/jetty-contexts.xml
etc/jetty-webapp-logging.xml
etc/jetty-testrealm.xml
#===========================================================The key entries here are the addition of the “logging” OPTION to load the classes in ${jetty.home}/lib/logging into the jetty server classpath, and the 2 new configuration files:

This adds a DeploymentManager lifecycle handler that configures the created Webapp’s Classloaders to deny acccess to any webapp (war) file contained logger implementations in favor of using the ones that exist on the server classpath. This is a concept known as Centralized Webapp Logging.