Message-ID: <160987677.300502.1369050843839.JavaMail.email@example.com> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_300501_918059796.1369050843839" ------=_Part_300501_918059796.1369050843839 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
Many users of Jetty will not ever need to write a Jetty Handler, but ins= tead will simply use the Servlet API. The existing jetty handlers for con= text, security, sessions and servlets can be reused without the need for ex= tension.
However, some users may have special requirements or footprint concerns = that prohibit the use of the full servlet API. For them implementing a Jet= ty handler is a straight forward way to provide dynamic web content with a = minimum of fuss.
See also the Architecture pa= ge to understand more about Handlers vs Servlets.
The org.mortbay.jetty.Handler= interface provides Jetty's core of content generation or manipulation. Cla= sses that implement this interface are used to coordinate requests, filter = requests and generate content.
The core API of the Handler interface is
The target of a handler is an identifier for the resource that should ha= ndle the passed request. This is normally the URI that is parsed from a HTT= P Request. However, in two key circumstances the target may differ from the= URI of the passed request:
The request and response objects used in the signature of the handle met= hod are HttpServletReque= st and HttpServletR= esponse. These are the standard APIs and are moderately restricted in w= hat can be done to the request and response. More often than not, access t= o the jetty implementations of these classes is required: Request and Response. However, as the request and response may be wrapped by h= andlers, filters and servlets, it is not possible to pass the implementatio= n directly. The following mantra will retrieve the core implementation ob= jects from under any wrappers:
Note that if the handler passes the request on to another handler, it sh=
ould use the
request/response objects passed in and not the base objects. This is to pre= serve any wrapping done by up stream handlers.
The dispatch argument indicates the state of the handling of the call an= d may be:
These mostly have significance for servlet and related handlers. For exa= mple, the security handler only applies authentication and authorization to= REQUEST dispatches.
A Handler may handle a request by:
The OneHandler emb= edded example shows how a simple handler may generate a response.
The normal servlet response API may be used and will typically set some = status, content headers and the write out the content:
It is also very important that a handler indicate that it has completed = handling the request and that the request should not be passed to other han= dlers:
Once the base request or response object is obtained, it may be modified= . Typically modifications are done to achieve:
The context of the request may also be updated:
Typically a modified request is passed to another handler and then the m= odifications are undone in a finally block afterwards:
The classes that implement the HandlerWrapper class are typically handler filters of thi= s style.
A handler may simply inspect the request and use the target, request URI= or other information to select another handler to pass the request to. Th= ese handlers typically implement the HandlerContainer interface.
See org.mortbay.j= etty.handler package for some examples.------=_Part_300501_918059796.1369050843839--