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

Porting to Jetty

For many developers, there should be little or no porting to be done to make a web application work on Jetty. If the application adheres to the standards, it should simply be a matter of configuration.

However, if the application uses non standard APIs from earlier version of Jetty or from other containers, then some porting work will be required. This page gives a brief overview of the changes needed to port a Jetty 5 handler to Jetty 6.

To start, please read the Architecture and Writing a Jetty Handler pages.

What has changed?

Request and Response Facades

In Jetty 5 there was a Jetty/Servlet duality principle in operation. The base request and response objects were Jetty classes and unrelated to servlets. The servlet API request and responses were facades over the jetty objects. While this worked, it was somewhat convoluted when it came to dispatches and requests that were reentrant with contexts. Also there was quiet a lot of code that needed to be implemented for both Jetty and Servlet requests/responses.

In Jetty 6, the duality is gone the jetty request and response classes extend the servlet classes. While initially this appears that this makes Jetty ONLY a servlet server, this
is not the case. The servlet request and response objects are not servlets and servlets are not required to handle requests. Many of the servlet API methods on request and response are inactive until the request has passed the appropriate handler. For example getSession will return null until the request has passed a SessionHandler which will call setSesson on the request.

Handler hierarchy

In Jetty 5, handlers were called sequentially until the request was handled. There was no interceptor style handling and complex pre/post methods were required to simulate interceptors.

With Jetty 6, the handlers may be organized either sequentially as Jetty 5, or nested as interceptors, which greatly simplifies dealing with dispatchers, JEE and other extended contexts.

Package structure

The package hierarchy has been simplified and a few classes have been rename to be more appropriate

Buffering and Scheduling

The buffer and scheduling has been completely redesigned and rewritten. However this should be transparent to almost all developers.

Deprecated methods

Many deprecated and unused methods have been removed.

Conversions

JETTY 5 CLASS

MATCHING JETTY 6 CLASS

SIMILAR JETTY 6 CLASS

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

  • 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