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 6 Next »

Porting from Jetty [345].x to Jetty 6

Jetty 6 represents a major refactoring of the Jetty code based and thus if you are coding to the Jetty APIs you can expect that some considerable reworking of your code will be required. However, if your code is mostly against the servlet specification or closely related to it, then little or no changes should be required and only configuration need be updated.

Architectural Changes

There have been two major changes in the architecture of Jetty 6, both intended to improve the modularity and allow interceptor style extension.

Merged HTTP Request API and Servlet Request API

In Jetty <=5, there was an API for pure Jetty HTTP requests and responses. The Jetty requests and responses where wrapped by the ServletHandler to provide the Servlet API for requests and responses. This architecture allowed for handlers to be written without servlet dependencies. However, given the re-entrant nature of Request Dispatches and the increasing involvement of the servlet spec in all common handlers (resoures, security, etc.). This Jetty/Servlet duality became an unwanted complexity when extending the server.

In Jetty 6, all requests and responses are based on the Servlet APIs requests and responses. This imposes a 136k JAR dependency on all jetty runtimes, but allows for significant reduction in the Jetty jar itself, as a parallel API is not required and much complexity is removed. Importantly this does not mean that all request are servlet requests and must be delivered by servlets. It simply means that jetty reuses the Servlet API as its own API for
common methods such as getParameter(String),getOutputStream() and getQueryString().

All Servlet facility, such as contexts, session, security, filters and servlets themselves are options. Only when the appropriate handlers are configured will the relevant parts of the servlet request/response API be active. For example:

  • Without a SessionHandler the getSession() will always return null.
  • Without a ContextHandler the getContext() path will always return null and the complete URI path will be available via getPathInfo()

Handlers are interceptors/filters.

In Jetty <=5, handlers were called in sequence, one after the other, until the request is marked as handled. This allowed for shallow calling stacks, but did not allows for simple and safe before/after handling using try {} finally {} constructs.

In Jetty 6, All handlers are formed into a strict containment tree rooted to the server and the normal arrangement is for handlers to implement their aspect of handling and then delegate the request to a contained handler. For a full configuration, the handling typically is as follows:

  1. The http://jetty.mortbay.org/apidocs/org/mortbay/jetty/Server.html delegates the request to the its configured handler, which is normally an instance of http://jetty.mortbay.org/apidocs/org/mortbay/jetty/handler/HandlerCollection.html.

Servlet 2.5

House Keeping

new package names.

deprecations

logging

Build and packaging

maven

  • 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