(1) Jetty vs Tomcat: A Comparative Analysis

(2)N ewbie Guide to Jetty

(3)J etty Documentation

(1) Jetty vs Tomcat: A Comparative

Analysis

prepared by Greg Wilkins - May, 2008

1. Introduction

Jetty and Tomcat are often cast as direct competitors. This paper is short comparison of the technical and

non-technical aspects of these two open source servlet containers.

2. Technical Comparisons

2.0. Architecture

The view from 20,000 feet is that Tomcat and Jetty are rather similar, they are both java applications

servers offering implementations of the 2.5 servlet specification with optional extras giving many JEE

features.

However, on closer inspection, the architectures of the two servers differ greatly, mostly because each

project as historically had a different focus:

Tomcat is first and foremost an application server. Its default incarnation is as software installed onto a

system, into which one can install applications. Tomcat can be stripped down to be embedded or built up

the be an full JEE server, but both are difficult exercises. Jetty is first and foremost a set of software

components that offer HTTP and servlet services. Jetty can be invoked and installed as a stand alone

application server or it can be easily embedded in an application or framework as a HTTP component, as a

simple servlet engine, as a feature rich servlet engine or as part of a full JEE environment.

It is the flexible component based architecture of Jetty that allows it to be flexibly deployed and integrated in

a diverse range of instances:

From mobile phones to large clusters of big iron servers

In software frameworks and tools: OSGi Equinox, OSGi Felix, Spring, Plexus, Cocoon, Tapestry,

Maven, Continuum, Fisheye, Grails, JRuby, Xbean, etc.

In JEE application servers: Geronimo, Jboss, Sybase EAServer, JOnAS and Glassfish

Embedded in applications, products and services from IBM, HP, Cisco, BEA, Yahoo, Eclipse (see

http://docs.codehaus.org/display/JETTY/Jetty+Powered)

As the basis for enhanced services such a SIP (www.cipango.org), Ajax JMS (www.activemq.org),

Asynchronous SOA services (Apache Camel)

As the servlet specification continues to grow and add additional features (annotations, automatic web

services, etc.) the cost of a standard servlet server is increasing. While Jetty will always continue to support

the standard incarnation, its modular approach allows deployments to be targeted at precisely the set of

services required without the additional complexities, inefficiencies and security concerns of unused

features.

2.1. Performance

Both Jetty and Tomcat offer good request per second performance and for any non-trivial web application it

is highly unlikely that either will be the main bottleneck.

General benchmarks are difficult to provide and web load profiles are greatly influenced by the actual

application and there is no substitute for specific application benchmarking. However, some generalized

observations can be made:

Tomcat tends to have slightly better performance when there are few very busy connections. It has a

slight advantage in request latency, which is most apparent when many requests/responses are sent

over a few connections without any significant idle time.

Jetty tends to have better scalability when there are many connections with significant idle time, as

is the situation for most web sites. Jetty's small memory footprint and advance NIO usage allows a

larger number of users per unit of available memory. Also the smaller footprint means that less

memory and CPU cache is consumed by the servlet container and more cache is available to speed

the execution of non-trivial applications.

Jetty also has better performance with regards to serving static content, as Jetty is able to use

advance memory mapped file buffers combined with NIO gather writes to instruct the operating

system to send file content at maximum DMA speed without entering user memory space or the

JVM.

2.2. Features

Both Jetty and Tomcat implement the core standard servlet 2.5 specification. Both servers offer a range of

EE inspired features such as JNDI, JTA, JMS, Mail servers, etc. Tomcat has an easy migration path for full

EE towards Jboss and Geronimo. Jetty has an easy migration path for full EE towards Geronimo, JBoss,

JOnAS, Sybase EAServer and, to some extent, Glassfish.

In the last 18 months, there has been an increased focus on web-2.0 features, specifically Ajax Push and

Comet. Jetty has been a leader in supporting the web-2.0 use-case from within the servlet model and

Webtide has formalized the Jetty approach in a proposal to JSR315 for the Servlet 3.0 that is likely to be

accepted as the standard way to provide the asynchronous servlets that are needed by web-2.0. In

comparison, the Tomcat project was slow to accept the Web-2.0 use-case, but are now offering an async

IO API that does fulfill the requirement. However that approach is not from within the servlet model, so

standard frameworks (JSP, Struts, etc) and techniques cannot be used.

3. Non-Technical Comparisons

3.0. Market Share

Selecting the market leader is often used as an important selection criteria. While market share is often a

good indication of technical strength, there are often many non-technical and/or historical reasons that may

contribute to and devalue market share as a selection criteria -specially in a market heavy influenced by

standards.

More over, the dominant market share once held by Tomcat is in decline, while Jetty's market share has

been steadily increasing over the last 18 months to the point where it now has 80% of Tomcat's market

share as reported in the Netcraft server surveys:

The Netcraft (http://www.netcraft.com) report surveys only measure a fraction of installations as many

servers have had their identifies disabled or are hidden behind load balancers or other web servers such as

Apache. If installed base is to be considered, then Jetty's use in many frameworks and tools (e.g. in the

Eclipse IDE from 3.3 onwards) would give Jetty a regular usage basis in the millions.

3.1. Reference Implementation

Tomcat was the reference implementation for servlets 2.4 and thus was often selected on that basis. From

version 2.5 onwards, Tomcat is no longer the reference implementation. Sun Microsystems forked

the Tomcat server to create Glassfish as the reference implementation for servlet 2.5 and servlet 3.0

as well as for JSP 2.1 onwards.

Jetty pays close attention to the specification and faithfully implements it. The Jetty developers were also

very active on JSR-154 for servlets 2.5 and now on JSR-315 for servlets 3.0. Thus Jetty not only follows

the servlet specification, but is able to influence the ongoing enhancement of the specification and

to anticipate upcoming changes.

3.2. Development Community

Jetty enjoys a stable development team and process, and has the same for more than a decade. Jetty has

been developed by the same core team since 1995 (using java 0.9) and has been supported by Mort Bay

Consulting and now by the partnership between Webtide LLC and Mort Bay. The project lives at the

independently minded codehaus.org project repository. The active group of people developing Jetty is of

moderate size and of a healthy, friendly and collaborative nature. The extended community in which

Jetty has developed includes close collaborations with many other open source projects including

Maven, ActiveMQ, Spring, Eclipse, JBoss, Geronimo, etc.

Tomcat has unfortunate history of a fragmented development community that is characterized more by

revolution than by collaboration or evolution. The transitions from Tomcat 3 to 4, 4 to 5, 5 to 5.5 and 5.5 to 6

have often resulted in the community splitting or of core developers leaving the project. The governance

and development issues of Tomcat have culminated in:

The loss of the status as Reference Implementations

The forking of the project to Sun's Glassfish

The project has switched from Commit and Review development to Review and Commit.

The upcoming move to Servlet 3.0 is going to require non-trivial enhancements to all servlet servers.

Having a unified harmonious, experienced and proven development team and process will be key to the

smooth transition to the new specification and the services and features that it will support.

4. Summary

The Tomcat project is a reasonable quality Java application server that has an established brand and large

user base. When used for it's prime role, Tomcat well fulfills the requirements. However it does lack the

flexibility as a software component and the capability as a project and community to adapt to

changing requirements and new innovative usage.

The Jetty project/team has an attitude and a history of being responsive to innovations and

changing requirements. This has resulted in a well architected software platform that has been

integrated and deployed in almost every environment and that is supported by a sizable, healthy

and growing community.

For more information about Jetty, please check out the official Jetty website at

http://jetty.mortbay.org/jetty/.

Jetty - Eclipse Project Creation Reviewwww.eclipse.org/proposals/jetty/Jetty_Creation_Review.pdf

Initial ContributionsThe initial code will be the current jetty trunk as located in svn at The Codehaus. A

bundle has already been delivered to begin the IP verification process.

DescriptionJetty is an open-source, standards-based, full-featured web server implemented entirely

in Java. It is released under the Apache 2.0 license and is therefore free for commercial use

and distribution. Once established as an Eclipse project, it will be dual-licensed, maintaining

its Apache 2.0 license, and adding the Eclipse Public License. Beyond the license addition,

which would not require any changes from the current large number of users or consuming

open source projects or commercial products with use of Jetty, the move is seen as having

numerous benefits for the projects and community...

• The transition would be a great time to clean up the project's packaging as it moves

to an org.eclipse name.

• The project will be focused on providing components and less on providing a

bundled application server stack. This will allow great focus of development energies

and further bring out Jetty's embedding strengths.

• The Eclipse IP policies will supplement Jetty's existing processes.

• Jetty could discuss handling the maintenance and updating the OSGI HTTP service

for Equinox as a module. The project is also interested in being involved in an effort

to modernize the standard for OSGI HTTP service. At this time, the project does not

envision revising its internal structure to use OSGi, but to stay with POJO that can

be configured with IOC/DI frameworks, which will work well for OSGi.

• The being a part of Eclipse's release trains would simplify spreading current versions

of Jetty for use in relevant projects within the Foundation that may be interested.

As history, Jetty was first created in 1995, and has benefited from input from a vast user

community and consistent and focused development by a stable core of lead developers.

There are many examples of Jetty in action on the Jetty Powered Page however, as Jetty

aims to be as unobtrusive as possible, countless websites and products are based around

Jetty, but Jetty is invisible!

Jetty can be used as:

• a stand-alone traditional web server for static and dynamic content

• a dynamic content server behind a dedicated HTTP server such as Apache using

mod_proxy or mod_jk

• an embedded component within a java application

• as a component to build an application server or Java EE server

This flexibility means that Jetty can be encountered in a number of different contexts:

• shipped with products to provide out-of-the-box usability eg Tapestry, Grails, JRuby

• distributed on CDs with books to make examples and exercises ready-to-run

• incorporated into applications as a HTTP transport eg JXTA, Cisco SESM

• integrated as a web container in JavaEE app servers eg Jonas, Geronimo, JBoss,

Sybase

• included as a component of an application eg Eclipse IDE, Hadoop

Some of the defining features of Jetty are:

• Simplicity

◦ Jetty is built by an assembly of simple components.

◦ Where possible features are added by aggregation of components rather

than creation of complex deep/optional APIs

◦ Assembly and configuration can be done by the java API, the jetty XML

configuration file, which is an IOC style mapping of XML to POJO APIs, other

IOC/component frameworks such as Spring and Plexus, OSGi activators,

and other XML to POJO mappings such as XBeans

• Embeddability

Jetty is designed to be a good component. This means that it can easily be

embedded in an application without forcing the application to adapt to it's

▪ Configuration files or formats

▪ File system layout

▪ Classloading hierarchy

▪ Usage of dependency injection and inversion of control patterns

• Pluggability

◦ Jetty is architected for pluggability. The API allows different implementations

of all of the principal Jetty components to be selected. At least one, but

sometimes more, implementations of a component are always provided.

However if these do not meet your needs, you are free to code your own

using the interfaces and abstract classes as a basis. This means that Jetty

can be easily customized to a particular application environment. This is

particularly useful when Jetty is acting as the web container in a JavaEE

server, as Jetty's pluggability ensures a tight integration with a host　container.

(2)N ewbie Guide to Jetty http://docs.codehaus.org/display/JETTY/Newbie+Guide+to+Jetty

Starting up Jetty

Starting with Jetty using start.jar and jetty.xml

Customizing your Jetty configuration

← Overview

Configuration file

Configuration file breakdown

Doctype (required)

Server (required)

Connectors (required)

Handlers (required)

ThreadPool (optional)

Security Realm (optional)

More

← Examples

Barebones Static Webapp Deployment

Static Webapp Deployment, version 2

Hot Deployment of Customized Contexts

File Server, One Handler

File Server, Multiple Handlers

Starting up Jetty

jetty-runner.jar - fast and easy way to run your webapp, without needing to install and administer a jetty distro.

Run it using java -jar jetty-runner.jar webappcontext. Further instructions can be found in the blog

entry linked to above.

start.jar - start from within your Jetty installation. Run it using java -jar start.jar configuration files

embed Jetty into your application

as a distribution package (RPM, .deb)

Maven Jetty Plugin

Starting with Jetty using start.jar and jetty.xml

These instructions assume that you have installed Jetty, although the configuration examples provided are applicable

to anywhere you pass in a jetty.xml file.

etc/jetty.xml is the default configuration file for Jetty. It demonstrates several basic functions, and can be used as

the basis for your own configuration. To immediately start up Jetty and begin looking around, go to $JETTY_HOME

and run this command:

java -jar start.jar

That starts up Jetty and applies the configuration specified in etc/jetty.xml. You can then view the page by visiting

http://localhost:8080/.

There are several additional options that can be set on the command line when using the supplied jetty.xml:

Option

name

Value

jetty.home directory which contains the etc, webapps, contexts folders. No trailing slash. Default value is the

directory from which you are running start.jar.

jetty.host host for the default connector. No default value.

jetty.port port for the default connector. Default value is 8080.

jetty.logs directory which contains the request logs. No trailing slash. Default value is ${jetty.home}/logs

To use these, do

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

etc/jetty.xml sets reasonable defaults, but you will want to customize Jetty to fit your needs. This section takes

you through configuring Jetty using an XML file. Most examples will be based from the jetty.xml file, but there are also

additional examples for several common use cases.

Overview

Configuration file

A server configuration file will look something like this:

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 .

<!DOCTYPE Configure PUBLIC "-//Mort Bay Consulting//DTD Configure//EN"

"http://jetty.mortbay.org/configure.dtd">

Server (required)

org.mortbay.jetty.Server is the main class for the Jetty HTTP server. It is the first instance called when you run the

server. It aggregates Connectors (HTTP request receivers) and request Handlers. The server is itself a handler and a

ThreadPool. Connectors use the ThreadPool methods to run jobs that will eventually call the handle method.

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

...

</Configure>

Connectors (required)

Implementations of the org.mortbay.jetty.Connector interface provide connectors for the HTTP protocol. It is here that

you set the ports that Jetty will listen on for incoming connections.

<Set name="connectors">

<Array type="org.mortbay.jetty.Connector">

<Item>

<New class="org.mortbay.jetty.nio.SelectChannelConnector">

<Set name="host"><SystemProperty name="jetty.host" /></Set>

<Set name="port"><SystemProperty name="jetty.port" default="8080"/></Set>

...

</New>

</Item>

</Array>

</Set>

Handlers (required)

Handlers process inbound requests. There is a handler which services web applications called

org.mortbay.jetty.webapp.WebAppContext. If you don't wish to use a full-blown application but just want to serve static

content and maybe some servlets, then you can use a ContextHandler and only configure those services you require.

The list of handlers that are defined for a Server is set by the following call:

<Set name="handlers">

<Array type="org.mortbay.jetty.Handler">

...

</Set>

ThreadPool (optional)

The ThreadPool class avoids the expense of thread creation by pooling threads for reuse after their run methods exit.

If the maximum pool size is reached, jobs wait for a free thread. By default there is no maximum pool size. Idle threads

timeout and terminate until the minimum number of threads are running. Configuring the ThreadPool is optional,

because the server falls back upon defaults. However, you may wish to customize the thread pool to better fit your

application. Example:

<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>

</New>

</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/realm.properties file:

<Set name="UserRealms">

<Array type="org.mortbay.jetty.security.UserRealm">

<Item>

<New class="org.mortbay.jetty.security.HashUserRealm">

<Set name="name">Test Realm</Set>

<Set name="config">etc/realm.properties</Set>

</New>

</Item>

</Array>

</Set>

More

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

the syntax for individual elements.

Examples

All examples assume that you are in $JETTY_HOME, and that the configuration file below is saved under

$JETTY_HOME/etc/myjetty.xml.

Barebones Static Webapp Deployment

Below is the bare minimum required to start up the Jetty server and start serving up standard web applications. This

will listen for connections on port 8080, and serve up any webapps placed under the $JETTY_HOME/webapps

folder:

<?xml version="1.0"?>

<!DOCTYPE Configure PUBLIC "-//Mort Bay Consulting//DTD Configure//EN" "http://jetty.mortbay.org/configure.dtd">

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

<Call name="addConnector">

<Arg>

<New class="org.mortbay.jetty.nio.SelectChannelConnector">

<Set name="port">8080</Set>

</New>

</Arg>

</Call>

<Set name="handler">

<New id="Handlers" class="org.mortbay.jetty.handler.HandlerCollection">

<Set name="handlers">

<Array type="org.mortbay.jetty.Handler">

<Item>

<New id="Contexts" class="org.mortbay.jetty.handler.ContextHandlerCollection"/>

</Item>

</Array>

</Set>

</New>

</Set>

<Call name="addLifeCycle">

<Arg>

<New class="org.mortbay.jetty.deployer.WebAppDeployer">

<Set name="contexts"><Ref id="Contexts"/></Set>

<Set name="webAppDir"><SystemProperty name="jetty.home" default="."/>/webapps</Set>

</New>

</Arg>

</Call>

</Configure>

Start up Jetty with this command:

java -jar start.jar etc/myjetty.xml

View your webapplications at http://localhost:8080/ webappfolder / . If you have no webapp defined for the root context

("/"), visiting http://localhost:8080/ will give you a normal 404 page.

Static Webapp Deployment, version 2

Here is a slightly more advanced version of the above:

<?xml version="1.0"?>

<!DOCTYPE Configure PUBLIC "-//Mort Bay Consulting//DTD Configure//EN" "http://jetty.mortbay.org/configure.dtd">

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

<Call name="addConnector">

<Arg>

<New class="org.mortbay.jetty.nio.SelectChannelConnector">

<Set name="host"><SystemProperty name="jetty.host" /></Set>

<Set name="port"><SystemProperty name="jetty.port" default="8080"/></Set>

</New>

</Arg>

</Call>

<Set name="handler">

<New id="Handlers" class="org.mortbay.jetty.handler.HandlerCollection">

<Set name="handlers">

<Array type="org.mortbay.jetty.Handler">

<Item>

<New id="Contexts" class="org.mortbay.jetty.handler.ContextHandlerCollection"/>

</Item>

<Item>

<New id="DefaultHandler" class="org.mortbay.jetty.handler.DefaultHandler"/>

</Item>

</Array>

</Set>

</New>

</Set>

<Call name="addLifeCycle">

<Arg>

<New class="org.mortbay.jetty.deployer.WebAppDeployer">

<Set name="contexts"><Ref id="Contexts"/></Set>

<Set name="webAppDir"><SystemProperty name="jetty.home" default="."/>/webapps</Set>

<Set name="parentLoaderPriority">false</Set>

<Set name="extract">true</Set>

<Set name="allowDuplicates">false</Set>

<Set name="defaultsDescriptor"><SystemProperty name="jetty.home" default="."/>/etc/webdefault.xml</Set>

</New>

</Arg>

</Call>

</Configure>

As before, start up Jetty with this command:

java -jar start.jar etc/myjetty.xml

View your webapplications at http://localhost:8080/ webappfolder / .

Other than the extra configuration settings, the biggest change is the addition of the

org.mortbay.jetty.handler.DefaultHandler, which deals with unhandled requests in the server. If you have no webapps

defined in the root context ("/"), visiting http://localhost:8080/ will 404, but will present a list of contexts that have been

deployed on the server. DefaultHandler also serves up a Jetty favicon.

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:

<Call name="addLifeCycle">

<Arg>

<New class="org.mortbay.jetty.deployer.ContextDeployer">

<Set name="contexts"><Ref id="Contexts"/></Set>

<Set name="configurationDir"><SystemProperty name="jetty.home" default="."/>/contexts</Set>

<Set name="scanInterval">5</Set>

</New>

</Arg>

</Call>

That sets up a ContextDeployer, which will scan the $JETTY_HOME/contexts folder every 5 seconds for changes to

the XML descriptors, and hot deploy as necessary. For more details, see ContextDeployer.

File Server, One Handler

Simple HTTP file server with one handler, similar to the embedded FileServer example and embedded OneHandler

example. This example serves up purely static files from your current directory:

<?xml version="1.0"?>

<!DOCTYPE Configure PUBLIC "-//Mort Bay Consulting//DTD Configure//EN" "http://jetty.mortbay.org/configure.dtd">

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

<Call name="addConnector">

<Arg>

<New class="org.mortbay.jetty.nio.SelectChannelConnector">

<Set name="port"><SystemProperty name="jetty.port" default="8080"/></Set>

</New>

</Arg>

</Call>

<Set name="handler">

<New id="ResourceHandler" class="org.mortbay.jetty.handler.ResourceHandler">

<Set name="resourceBase">.</Set>

</New>

</Set>

</Configure>

Note that ResourceHandler does not allow directory listing; if you visit a directory with no welcome files, you will get a

403 Forbidden error message. Try the exact path to the file.

If you just want a specific context to serve static content, while still serving dynamic web applications from other

contexts, configure your server to allow hot deployment (see previous example), then set up a context to serve up

Static Content.

File Server, Multiple Handlers

Simple HTTP file server with request logging. Similar to the embedded FileServer example and embedded

ManyHandlers example

<?xml version="1.0"?>

<!DOCTYPE Configure PUBLIC "-//Mort Bay Consulting//DTD Configure//EN" "http://jetty.mortbay.org/configure.dtd">

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

<Call name="addConnector">

<Arg>

<New class="org.mortbay.jetty.nio.SelectChannelConnector">

<Set name="port"><SystemProperty name="jetty.port" default="8080"/></Set>

</New>

</Arg>

</Call>

<Set name="handler">

<New id="Handlers" class="org.mortbay.jetty.handler.HandlerCollection">

<Set name="handlers">

<Array type="org.mortbay.jetty.Handler">

<Item>

<New id="ResourceHandler" class="org.mortbay.jetty.handler.ResourceHandler">

<Set name="resourceBase">./logs</Set>

</New>

</Item>

<Item>

<New id="RequestLog" class="org.mortbay.jetty.handler.RequestLogHandler"/>

</Item>

</Array>

</Set>

</New>

</Set>

<Ref id="RequestLog">

<Set name="requestLog">

<New id="RequestLogImpl" class="org.mortbay.jetty.NCSARequestLog">

<Set name="filename"><SystemProperty name="jetty.logs" default="./logs"/>/request.log</Set>

<Set name="append">false</Set>

</New>

</Set>

</Ref>

</Configure>

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 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 logfile's name does not contain a date; see jetty.xml for an extended configuration which

does.

Either a HandlerCollection or a HandlerList can be used when setting multiple handlers.

org.mortbay.jetty.handler.HandlerCollection calls all handlers in turn. org.mortbay.jetty.handler.HandlerList calls each

contained handler until either an exception is thrown, the response is committed,or a positive response status is sent.

In this case, HandlerCollection was chosen so that the RequestLogHandler could log the requests.

(3)J etty Documentation

http://docs.codehaus.org/display/JETTY/Jetty+Documentation

Jetty Documentation Wiki top level

Jetty <= 6 @ codehaus

Jetty >= 7 @ eclipse

Jetty >= 7 wiki @ eclipse

Jetty Powered

About Jetty

Getting Started

Downloading Jetty

Installing Jetty-6.1.x, Jetty-7.0.x

Running Jetty-6.1.x, Jetty-7.0.x

← Windows Service Wrapper

← Debian Packages

← RPMs

Supported JVMs

References

Jetty Architecture

Jetty Xml Configuration Syntax Reference

Javadoc

xref

Walkthrough: jetty.xml

Jetty Security

Tutorials

Newbie Guide to Jetty

Writing a Jetty Handler

Embedding Jetty

Porting to jetty6

Upgrade from jetty6 to jetty7(eclipse)

Getting Started with Jetty on www.itjungle.com

Development

Contributing

Jetty Coding Standards

SVN:

← jetty-7 (developers svn+ssh)

← jetty-7 accessories (developers https)

← jetty-6 (developers https)

← jetty-6 contrib (developers https)

← hightide (developers https)

Codehaus CI

Building from Source

JIRA

Jetty-6.1.x Release Procedure

Jetty-7.0.x Release Procedure

Website Release Procedure

Building Jetty RPMs

Feature Guides

Asynchronous Servlets

Suspendable Requests

Continuations

Quality of Service Filter

Asynchronous REST & Jetty HTTP Client

[Asynchronous Web Services]

Asynchronous Proxy Servlet

AJAX / Comet

Continuations for Ajax Comet

Cometd (aka Bayeux)

← Acknowledged Messages

← [Clustering with Oort] coming soon

ActiveMQ

Maven Support

Maven Jetty Plugin

← Which files are scanned by the Jetty Maven Plugin

Maven Jetty Jspc Plugin

Maven web app project archetypes courtesy of Webtide

Ant Support

Ant Jetty Plugin

IDEA

Debugging Jetty with IntelliJ IDEA

Eclipse Workbench

Importing Jetty Source into Eclipse

Debugging Jetty with Eclipse

Debugging with the Maven Jetty Plugin inside Eclipse

Jetty Eclipse Plugin - Web Tooling Support

JettyLauncher Soon to be upgraded to jetty6

run-jetty-run

Cargo

Cargo container-agnostic testing tools

Useful Servlets and Filters

Servlets Bundled with Jetty

Mobile Computing

Google Android: i-jetty

JME CDC

JEE Server Integrations

Apache Geronimo JEE

RedHat JBoss

Grizzly Connector from Glassfish

Sybase EAServer

Remote Glassfish EJBs from Jetty

Web Frameworks

DWR

MyFaces

JSF Reference Implementation

Jakarta Slide

Google Web Toolkit (GWT)

Jetspeed2

ICEfaces

EJB

Jetty and Spring EJB3 (Pitchfork)

JBoss EJB3

ObjectWeb EasyBeans (aka JOnAS EJB3 container)

Remote Glassfish EJBs from Jetty

Clustering Technologies

[Gigaspaces ] coming soon

Terracotta (generic Terracotta version)

Terracotta (Jetty version)

WADI

see also Session Clustering using a Database

Infrastructure

Atomikos Transaction Manager

JOTM

Bitronix Transaction Manager

ActiveMQ

Binding JAX-WS 2.x Endpoints to Jetty contexts

Java-monitor

OSGi

Jetty OSGi Powered Products

OSGi Tips

Jetty as the HTTP Service in Equinox

Jetty as the HTTP Service in Felix

Jetty as the HTTP Service in PAX

ProSyst mBedded Server Equinox Edition

Jetty in Spring Dynamic Modules

Jetty in JOnAS 5

Amazon EC2

Jetty on Amazon EC2

Other

JIRA

How Tos

General

Running Jetty with jconsole

Debug Logging

Useful web developer tools

How to test Servlets

File Upload in jetty6

General Configuration

Configuring Jetty

The jetty.xml file

The jetty-web.xml file

The jetty-env.xml file

The webdefault.xml file

The override web.xml file

Temporary Directories

System Properties

How to capture stderr/stdout

Suppressing HTTP Server Header

Classloading

JSP Configuration

Serving aliased/symbolically linked files

Customizing startup

Using XBean to configure Jetty

How to Create Custom Error Pages

GZIP Compression

Contexts and Web Applications

Web Application Deployer (static deploy)

Context Deployer (hot deploy!)

Static Content

Relocating / Redirecting Contexts

Rewrite Handler

see also Embedding Jetty and Maven Jetty Plugin

Multiple WebApp Source Directory

Connectors

Configuring Connectors

Configuring SSL

← Ssl Connector Guide

← Configure SSL Cipher Suites

Apache mod_proxy (Reverse Proxy)

Apache mod_proxy_ajp and mod_jk for AJP

Running on port 80 as non-root user

Associating webapps with ports and virtual hosts

Serving different webapps from different ports

Virtual hosts

Thread Pools

Bounded ThreadPool

Queued ThreadPool TODO

Security

Jetty Security reports.

Securing Jetty

Securing Passwords

Realms

← JAAS Realms

How to Configure Security with Embedded Jetty

Management

Server Log (coming soon)

Request Logging

Collecting statistics

Graceful shutdown

JMX

Annotations

Annotations, Resource Injection and Lifecycle Callbacks

JNDI Services

Using JNDI

← DataSource Examples

JSP

JSP 2.0 and JSP 2.1

JSP Configuration

Sessions

Session Configuration

Persisting Sessions

Single Sign On - Jetty HashSSORealm

Clustering

Session Clustering using a Database

[Session Clustering using Gigaspaces] coming soon

Session Clustering with Terracotta(Generic)

Session Clustering with Terracotta(Jetty)

Session Clustering with WADI

Optimizing

Optimizing with Last-Modified and Cache-Control

Optimizing Browser Caching

Optimizing on High Load Servers

Other

International Characters and Character Encodings

Intercepting Connections and Requests

Using Jetty to Put a Website on a CD (Jetty 5 - but same principle applies )

Trouble shooting

No warning starting Jetty on port already in use (on Windows)

Files locked on Windows

Slow File Serving on Windows 2003

Save could not be completed

Temporary directory files not deleted

Welcome files not working

Invalid Content Length Log Message

JSP expression do not evaluate

Keep Generated

Post requests using nio https hang

Security Constraints and Welcome Files

SSL does not work with DSA key

Problems with JAAS 6.0.x

NullpointerException in jasper Localizer class

Zip exception reading jar or war files

Connectors slow to startup

Frequent disconnects when downloading large files

OutofMemory Errors

J2SE 6 Problems

Webapp suddenly stopped working

FAQ - Frequently Asked Questions

General

Why is it called Jetty?

How do I submit a support question ?

Porting to jetty6