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
To understand Jetty configuration, you need to understand the "How" and the "What". This section covers how to configure Jetty in terms of what mechanisms exist to perform configuration. The next section gives an overview of the action components and fields that you can configure with these mechanisms.
The core components of Jetty are simply Plain Old Java Objects (POJOs); the process of configuring Jetty is mostly the process of instantiating, assembling and setting fields on the Jetty POJOs. You can achieve this either by:
Writing Java code to directly instantiate and assemble Jetty objects. This is referred to as Embedding Jetty.
Using Jetty XML configuration, which is an Inversion
of Control (IoC) framework, to instantiate and assemble Jetty
objects as XML objects. The
etc/jetty.xml file is
the main Jetty XML configuration file, but there are many other
files included in the jetty distribution.
Because the main Jetty configuration is done by IoC, the Jetty API documentation is the ultimate configuration reference.
The Jetty distribution uses the following configuration files to instantiate, inject and start server via the start.jar mechanism
The Jetty Start mechanism uses the command line, the
$JETTY_BASE/start.d/*.ini files to create an effective
command line of arguments. Arguments may be:
XML files in Jetty IoC (or spring) XML format
Module activations in the form --module=name
Property in the form of name=value, used to parameterize Jetty IoC XML
A standard Java property file containing additional start properties
Other start.jar options (see java -jar start.jar --help)
Some JVM options
It is the ini files are located in the jetty base (if different from jetty home) that are typically edited to change the configuration (Eg change ports)
$JETTY_HOME/modules/*.mod files contain the
definition of modules that can be activated by --module=name. Each
mod file defines:
Module dependencies for ordering and activation
The libraries needed by the module to be added to the classpath
The XML files needed by the module to be added to the effective command line
Files needed by the activated module
A template ini file to be used when activating with the --add-to-start=name option
Typically module files are rarely edited and only for
significant structural changes. The *.mod files are normally located
$JETTY_HOME/modules/, but extra or edited modules may
be added to
$JETTY_BASE/module. If module changes are
required, it is best practise to copy the particular *.mod file from
$JETTY_BASE/modules/ before being modified.
XML files in Jetty IoC XML format or spring IoC format are listed either on the command line, in ini files or are added to the effective command line by a module definition. The XML files instantiate and inject the actual Java objects that comprise the server, connectors and contexts. Because Jetty IoC XML files use properties, most common configuration tasks can be accomplished without editing these XML files and can instead be achieved by editing the properti in the corresponding ini files.
The XML files are normally located
$JETTY_HOME/etc/, but extra or edited XML files may be
$JETTY_BASE/etc/. If XML configuration changes
are required, it is best practise to copy the XML file from
before being modified.
In addition to the start configuration files described above, the configuration of the server can use the following file:
Any XML files in Jetty IoC XML format or spring IoC format that is discovered in the webapps directory are used by the deploy module to instantiate and inject HttpContext instances to create a specific context. These may be standard web applications or bespoke contexts created from special purpose handlers.
Specification defines the
web.xml deployment descriptor that
defines and configures the filters, servlets and resources a web
application uses. The Jetty WebAppContext component uses this
XML format to:
Set up the default configuration of a web application context.
Interpret the application-specific configuration supplied
with a web application in the
Interpret descriptor fragments included in the
META-INF directory of Jar files within
Normally the web.xml file for a web application is found in the WEB-INF/web.xml location within the war file/directory or as web.xml fragments with jar files found in WEB-INF/lib. Jetty also supports multiple web.xml files so that a default descriptor may be applied before WEB-INF/web.xml (typically set to etc/webdefault.xml by the deploy module) and an override descriptor may be applied after WEB-INF/web.xml (typically set by a context XML file see test.xml)
Standard Java property files are also used for Jetty configuration in several ways:
To parameterize Jetty IoC XML via the use of the Property element.
To configure the default logging mechanism (StdErrLog). You can also plug in other logging frameworks, and also use property files (for example, log4j).
As a simple database for login usernames and credentials.
To understand the Jetty IoC XML format, consider the following example of an embedded Jetty server instantiated and configured in java:
Jetty IoC XML format allows you to instantiate and configure the exact same server in XML without writing any java code:
In practise, most commonly used Jetty features have XML files that
are included in the standard distribution in the
directory. Thus configuring Jetty is often a matter of just editing
existing XML files and altering the property values injected into