Versions Compared


  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: added link to running jetty 6, tweaked heading structure typos


Code Block
java -Doption1=value -Doption2=value -jar start.jar etc/jetty.xml

More information about starting and stopping Jetty can be found in Running Jetty-6.1.x.

Customizing your Jetty configuration


Code Block
<?xml version="1.0"?>
<!DOCTYPE Configure PUBLIC "-//Mort Bay Consulting//DTD Configure//EN" "">

<Configure id="Server" class="org.mortbay.jetty.Server">

  <!-- required configuration -->
  <!-- connectors -->
  <!-- handlers -->
  <!-- webapps/contexts -->

  <!-- optional configuration -->
  <!-- threadpool -->
  <!-- session id manager -->
  <!-- authentication realms -->
  <!-- request logs -->
  <!-- extra server options -->


Configuration file breakdown

Doctype (required)

All tags and elements declared inside jetty.xml will be pointing to this resource, configure.dtd. This means that only tags and elements based from this data type file will be valid .


Code Block
<Set name="ThreadPool">
 <New class="org.mortbay.thread.QueuedThreadPool">
    <Set name="minThreads">10</Set>
    <Set name="maxThreads">200</Set>
    <Set name="lowThreads">20</Set>
    <Set name="SpawnOrShrinkAt">2</Set>

Security Realm (optional)

If you want to use authentication and authorisation, then you need to define a Security realm. There is no limit to the number or types of realms that you can define for a Server. The following example sets up a security realm that is populated by the etc/ file:

Code Block
<Set name="UserRealms">
  <Array type="">
    <New class="">
     <Set name="name">Test Realm</Set>
     <Set name="config">etc/</Set>


For a more detailed explanation of the default settings, see the jetty.xml walkthrough. The Syntax Reference explains the syntax for individual elements.


For more details about configuring static deployment, see WebAppDeployer.

Hot Deployment of Customized Contexts

In addition to deploying webapps at start-up, you can also do hot deployment: configure a context deployer which scans a specific directory for XML configuration files, and deploys/redeploys/undeploys a webapp if its configuration file has been modified, added, or removed. These configuration files also allow you to configure certain Jetty-specific per-context settings; configuration file and its format is specific to Jetty. To keep things short, I am not going to reproduce the entire configuration. Add this block to either of the previous examples:


Similar to the one handler example, but defines multiple handlers. A handler can be configured either as soon as it is declared, or further down using the Ref tag. There is no difference in effect between the two. That example serves up static files in the logs directory under your current directory, and logs all requests since the server was last started to request.log.

To see the demo this in action, go to http://localhost:8080/request.log and refresh a few times (you may need to hard refresh, to make sure you are not seeing a cached copy of the data).

For simplicity's sake, the log files do logfile's name does not contain a date; see jetty.xml for an extended configuration which does.


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