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