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