Difference between revisions of "Jetty/Howto/Write Jetty Handler"

Latest revision as of 15:11, 23 April 2013

Introduction

Jetty 7 and Jetty 8 are now EOL (End of Life)

THIS IS NOT THE DOCUMENTATION YOU ARE LOOKING FOR!!!!!






All development and stable releases are being performed with Jetty 9 and Jetty 10.






This wiki is now officially out of date and all content has been moved to the Jetty Documentation Hub

Direct Link to updated documentation: http://www.eclipse.org/jetty/documentation/current/writing-custom-handlers.html

The Handler is the Jetty component that deals with received requests.

Many users of Jetty will not ever need to write a Jetty Handler, but instead will simply use the Servlet API. The existing Jetty handlers for context, security, sessions and servlets can be reused without the need for extension. However, some users might have special requirements or footprint concerns that prohibit the use of the full servlet API. For them implementing a Jetty handler is a straight forward way to provide dynamic web content with a minimum of fuss.

See also the Jetty Architecture page to understand more about Handlers vs. Servlets.

The Handler API

The Handler interface provides Jetty's core of content generation or manipulation. Classes that implement this interface are used to coordinate requests, filter requests and generate content.

The core API of the Handler interface is

public void handle(String target, Request baseRequest, HttpServletRequest request, HttpServletResponse response)
    throws IOException, ServletException

An implementation of this method can handle a request, pass the request onto another handler (or servlet), or it can modify and/or wrap the request and then pass it on. This gives three styles of handler:

Coordinating Handlers - Handlers that route requests to other handlers (HandlerCollection, ContextHandlerCollection) Filtering Handlers - Handlers that augment a request and pass it on to other handlers (HandlerWrapper, ContextHandler, SessionHandler) Generating Handlers - Handlers that produce content (ResourceHandler and ServletHandler)

The target

The target of a handler is an identifier for the resource that should handle the passed request. This is normally the URI that is parsed from an HTTP Request. However, in two key circumstances the target may differ from the URI of the passed request:

1. If the request has been dispatched to a named resource, such as a named servlet, then the target is the name of that resource.
2. If the request is being made by a call to Request Dispatcher, then the target is the URI of the included resource and will be different to the URI of the actual request.

The Request and Response

The request and response objects used in the signature of the handle method are Servlet Request and Servlet Response. These are the standard APIs and are moderately restricted in what can be done to the request and response. More often than not, access to the jetty implementations of these classes is required: Request and Response. However, as the request and response may be wrapped by handlers, filters and servlets, it is not possible to pass the implementation directly. The following mantra retrieves the core implementation objects from under any wrappers:

Request base_request = request instanceof Request ? (Request)request : HttpConnection.getCurrentConnection().getRequest();
Response base_response = response instanceof Response ? (Response)response : HttpConnection.getCurrentConnection().getResponse();

Note that if the handler passes the request on to another handler, it should use the
request/response objects passed in and not the base objects. This is to preserve any wrapping done by up stream handlers.

The dispatch

The dispatch argument indicates the state of the handling of the call and may be:

• REQUEST == 1 - An original request received from a connector.
• FORWARD == 2 - A request being forwarded by a RequestDispatcher
• INCLUDE == 4 - A request being included by a RequestDispatcher
• ERROR == 8 - A request being forwarded to a error handler by the container.

These mostly have significance for servlet and related handlers. For example, the security handler only applies authentication and authorization to REQUEST dispatches.

Handling Requests

A Handler may handle a request by:

Generating a Response

The OneHandler embedded example shows how a simple handler can generate a response.

The normal servlet response API can be used and will typically set some status, content headers and then write out the content:

 
 response.setContentType("text/html");
 response.setStatus(HttpServletResponse.SC_OK);
 response.getWriter().println("<h1>Hello OneHandler</h1>");

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

 
 Request base_request = (request instanceof Request) ? (Request)request:HttpConnection.getCurrentConnection().getRequest();
 base_request.setHandled(true);

Filtering the Request and/or Response

Once the base request or response object is obtained, you can modify it. Typically you would make modifications to accomplish:

• breaking the URI into contextPath, servletPath and pathInfo components
• associating a resource base with a request for static content.
• associating a session with a request
• associating a security principal with a request
• changing the URI and paths during a request dispatch forward to another resource.

You can also update the context of the request:

• Setting the current threads context classloader
• Setting thread locals to identify the current ServletContext.

Typically a modified request is passed to another handler and then the modifications are undone in a finally block afterwards:

 
 try
 {
    base_request.setSession(a_session);
    next_handler.handle(target,request,response,dispatch);
 }
 finally
 {
    base_request.setSession(old_session);
 }

The classes that implement the HandlerWrapper class are typically handler filters of this style.

Passing the Request and Response to another handler

A handler might simply inspect the request and use the target, request URI or other information to select another handler to pass the request to. These handlers typically implement the HandlerContainer interface.

Examples include:

• Class Handler Collection - A collection of handlers, where each handler is called regardless of the state of the request. This is typically used to pass a request to a ContextHandlerCollection and then the a RequestLogHandler
• HandlerList - A list of handlers which are called in turn until the request state is set as handled.
• ContextHandlerCollection - collection of Handlers of which one is selected by best match for the context path.

More About Handlers

See Jetty 7 Latest Source XRef and Jetty 7 Latest JavaDoc for detailed information on each Jetty handler.