Jetty has moved!
Jetty is a project at the Eclipse Foundation.
Homepage:http://www.eclipse.org/jetty
Downloads: http://download.eclipse.org/jetty/
Documentation:http://www.eclipse.org/jetty/documentation/current/
About:http://www.eclipse.org/jetty/about.php
Jetty Powered:http://www.eclipse.org/jetty/powered/
Contact the core Jetty developers at www.webtide.com
private support for your internal/customer projects ... custom extensions and distributions ... versioned snapshots for indefinite support ... scalability guidance for your apps and Ajax/Comet projects ... development services from 1 day to full product delivery
Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 22 Next »

Jetty 6 Architecture

View from 20,000 feet

The Jetty Server is the plumbing between a collection of Connectors that accept HTTP connections, and a collection of Handlers that service requests from the connections and produce responses, with the work being done by threads taken from a thread pool.

Icon

While the jetty request/responses are derived from the Servlet API, the full features of the servlet API are only available if the appropriate handlers are configured. For example, the session API on the request is inactive unless the request has been passed to a Session Handler. The concept of a Servlet itself is implemented by a Servlet Handler. If servlets are not required, there is very little overhead in the use of the servlet request/response APIs

Thus a Jetty server may be built using simply connectors and handlers, but without using Servlets.

Patterns

The implementation of Jetty follows some fairly standard patterns. Most abstract concepts such as Connector, Handler and Buffer are captured by interfaces. Generic handling for those interfaces is then provided in an Abstract implementation such as AbstractConnector, AbstractHandler and AbstractBuffer.

The JSR77 inspired life cycle of most jetty components is represented by LifeCycle interface and the AbstractLifeCycle implementation used as the base of many Jetty components.

Jetty provides is own IO Buffering abstract over String, byte arrays and NIO buffers. This allows for greater portability of Jetty as well as hiding some of the complexity of the NIO layer and it's advanced features.

Connectors

Icon

This diagram is a little out of date, as a Connection interface has been extracted out of HttpConnector to allow support for the AJP protocol

The connectors represent the protocol handlers that accept connections, parse requests and generate responses. The different types of connectors available are based on the protocols , scheduling model and IO APIs used:

Handlers

The Handler is the component that deals with received requests. The core API of a handler is the handle method:

An implementation of this method may handle the request, pass the request onto another handler (or servlet) or may modify and/or wrap the request and then pass it on. This gives three styles of Handler:

  1. Coordinating Handlers - Handlers that route requests to other handlers (eg HandlerCollection, ContextHandlerCollection)
  2. Filtering Handlers - Handlers that augment a request and pass it on to other handlers (eg. HandlerWrapper, ContextHandler, SessionHandler)
  3. Generating Handlers - Handlers that produce content (eg ResourceHandler and ServletHandler)

See also Writing a Jetty Handler.

Servlets

The ServletHandler is a Handler that generates content by passing the request to any configured Filters and then to a Servlet mapped by a URI pattern.

A ServletHandler is normally deployed within the scope of a servlet Context, which is a ContextHandler that provides convenience methods for mapping URIs to servlets.

Filters and Servlets may also use a RequestDispatcher to reroute a request to another context or another servlet in the current context.

Context

Contexts are handlers that group other handlers below a particular URI context path or a virtual host. Typcially a context may have :

  • A context path that defines which requests are handled by the context (eg /myapp )
  • A resource base for static content (a docroot)
  • A class loader to obtain classes specific to the context (typically docroot/WEB-INF/classes)
  • Virtual host names

Contexts implementations include:

A web application context combines handlers for security, session and servlets in a single unit that can be configured with a web.xml descriptor.

Web Applications

A WebAppContext is a derivation of the servlet Context that supports the standardized layout of a web application and configuration of session, security, listeners, filter, servlets and JSP via a web.xml descriptor normally found in the WEB-INF directory of a webapplication.

Essentially the WebAppContext is a conveniance class to assist the construction and configuration of other handlers to achieve a standard web application configuration.

Configuration is actually done by pluggable implementations of the Configuration class and the prime among these is WebXmlConfiguration

  • No labels
Contact the core Jetty developers at www.webtide.com
private support for your internal/customer projects ... custom extensions and distributions ... versioned snapshots for indefinite support ... scalability guidance for your apps and Ajax/Comet projects ... development services from 1 day to full product delivery