Jetty Vs Tomcat

(1)Jetty vs Tomcat: A Comparative Analysis

(2)Newbie Guide to Jetty

(3)Jetty 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 Review
www.eclipse.org/proposals/jetty/Jetty_Creation_Review.pdf
Initial Contributions
The 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.
Description
Jetty 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 Value
name

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


<Call name="addConnector">

<Arg>


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

</New>

</Arg>

</Call>

<Set name="handler">

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



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





<Arg>


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


</New>

</Arg>

</Call>





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


<Arg>

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


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


<Arg>

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


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





<Arg>



</New>

</Arg>

</Call>


<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





<Arg>



</New>

</Arg>

</Call>





<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

Jetty Vs Tomcat

More Related Content

What's hot

Viewers also liked

Similar to Jetty Vs Tomcat

More from Tomoaki Sawada

Recently uploaded

Jetty Vs Tomcat