Jetty Vs Tomcat
-
Upload
tomoaki-sawada -
Category
Technology
-
view
56.938 -
download
5
description
Transcript of Jetty Vs Tomcat
(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