Section 7.1.1 Merged HTTP Request and Servlet Request API
In Jetty versions 5 and lower, there was an API for pure Jetty HTTP requests and responses. The Jetty requests and responses were wrapped by the ServletHandler to provide the Servlet API for requests and responses. This architecture allowed handlers to be written without servlet dependencies. Given the re-entrant nature of Request Dispatches and the increasing involvement of the servlet spec in all common handlers (resources, security, etc.), however, 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 requests 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, the relevant parts of the servlet request/response API become active. For example:
- Without a SessionHandler the getSession() always returns null.
- Without a ContextHandler the getContext() path always returns null and the complete URI path will be available via getPathInfo().