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
Jetty has a slogan, "Don't deploy your application in Jetty, deploy Jetty in your application!" What this means is that as an alternative to bundling your application as a standard WAR to be deployed in Jetty, Jetty is designed to be a software component that can be instantiated and used in a Java program just like any POJO. Put another way, running Jetty in embedded mode means putting an HTTP module into your application, rather than putting your application into an HTTP server.
This tutorial takes you step-by-step from the simplest Jetty server instantiation to running multiple web applications with standards-based deployment descriptors. The source for most of these examples is part of the standard Jetty project.
To embed a Jetty server the following steps are typical and are illustrated by the examples in this tutorial:
The following code from SimplestServer.java instantiates and runs the simplest possible Jetty server:
This runs an HTTP server on port 8080. It is not a very useful server as it has no handlers, and thus returns a 404 error for every request.
To produce a response to a request, Jetty requires that you set a Handler on the server. A handler may:
Examine/modify the HTTP request.
Generate the complete HTTP response.
Call another Handler (see HandlerWrapper).
Select one or many Handlers to call (see HandlerCollection).
The following code based on HelloHandler.java shows a simple hello world handler:
The parameters passed to the handle method are:
target–the target of the request, which is either a URI or a name from a named dispatcher.
baseRequest–the Jetty mutable request object, which is always unwrapped.
request–the immutable request object, which may have been wrapped by a filter or servlet.
response–the response, which may have been wrapped by a filter or servlet.
The handler sets the response status, content-type, and marks the request as handled before it generates the body of the response using a writer.
To allow a Handler to handle HTTP requests, you must add it to a Server instance. The following code from OneHandler.java shows how a Jetty server can use the HelloWorld handler:
One or more handlers do all request handling in Jetty. Some handlers select other specific handlers (for example, a ContextHandlerCollection uses the context path to select a ContextHandler); others use application logic to generate a response (for example, the ServletHandler passes the request to an application Servlet), while others do tasks unrelated to generating the response (for example, RequestLogHandler or StatisticsHandler).
Later sections describe how you can combine handlers like aspects. You can see some of the handlers available in Jetty in the org.eclipse.jetty.server.handler package.
Complex request handling is typically built from multiple Handlers that you can combine in various ways. Jetty has several implementations of the HandlerContainer interface:
Holds a collection of other handlers and calls each handler in order. This is useful for combining statistics and logging handlers with the handler that generates the response.
A Handler Collection that calls each handler in turn until either an exception is thrown, the response is committed or the request.isHandled() returns true. You can use it to combine handlers that conditionally handle a request, such as calling multiple contexts until one matches a virtual host.
A Handler base class that you can use to daisy chain handlers together in the style of aspect-oriented programming. For example, a standard web application is implemented by a chain of a context, session, security and servlet handlers.
A specialized HandlerCollection that uses the longest prefix of the request URI (the contextPath) to select a contained ContextHandler to handle the request.
Much of the standard Servlet container in Jetty is implemented with HandlerWrappers that daisy chain handlers together: ContextHandler to SessionHandler to SecurityHandler to ServletHandler. However, because of the nature of the servlet specification, this chaining cannot be a pure nesting of handlers as the outer handlers sometimes need information that the inner handlers process. For example, when a ContextHandler calls some application listeners to inform them of a request entering the context, it must already know which servlet the ServletHandler will dispatch the request to so that the servletPath method returns the correct value.
The HandlerWrapper is specialized to the ScopedHandler abstract class, which supports a daisy chain of scopes. For example if a ServletHandler is nested withing a ContextHandler, the order and nesting of execution of methods is:
Thus when the ContextHandler handles the request, it does so within the scope the ServletHandler has established.
The FileServer example shows how you can use a ResourceHandler to serve static content from the current working directory:
Notice that a HandlerList is used with the ResourceHandler and a DefaultHandler, so that the DefaultHandler generates a good 404 response for any requests that do not match a static resource.
In the previous examples, the Server instance is passed a port number and it internally creates a default instance of a Connector that listens for requests on that port. However, often when embedding Jetty it is desirable to explicity instantiate and configure one or more Connectors for a Server instance.
The following example, OneConnector.java, instantiates, configures, and adds a single HTTP connector instance to the server:
In this example the connector handles the HTTP protocol, as that is the default for the ServerConnector class.
When configuring multiple connectors (for example, HTTP and HTTPS), it may be desirable to share configuration of common parameters for HTTP. To achieve this you need to explicitly configure the ServerConnector class with ConnectionFactory instances, and provide them with common HTTP configuration.
The ManyConnectors example, configures a server with two ServerConnector instances: the http connector has a HTTPConnectionFactory instance; the https connector has a SslConnectionFactory chained to a HttpConnectionFactory. Both HttpConnectionFactories are configured based on the same HttpConfiguration instance, however the HTTPS factory uses a wrapped configuration so that a SecureRequestCustomizer can be added.
Servlets are the standard way to provide application logic that handles HTTP requests. Servlets are similar to a Jetty Handler except that the request object is not mutable and thus cannot be modified. Servlets are handled in Jetty by A ServletHandler. It uses standard path mappings to match a Servlet to a request; sets the requests servletPath and pathInfo; passes the request to the servlet, possibly via Filters to produce a response.
The MinimalServlets example creates a ServletHandler instance and configures a single HelloServlet:
A ContextHandler is a ScopedHandler that responds only to requests that have a URI prefix that matches the configured context path. Requests that match the context path have their path methods updated accordingly and the contexts scope is available, which optionally may include:
A Classloader that is set as the Thread context classloader while request handling is in scope.
A set of attributes that is available via the ServletContext API.
A set of init parameters that is available via the ServletContext API.
A base Resource which is used as the document root for static resource requests via the ServletContext API.
A set of virtual host names.
When many contexts are present, you can embed a ContextHandlerCollection to efficiently examine a request URI to then select the matching ContextHandler(s) for the request. The ManyContexts example shows how many such contexts you can configure:
A ServletContextHandler is a specialization of ContextHandler with support for standard sessions and Servlets. The following OneServletContext example instantiates a DefaultServlet to server static content from /tmp/ and a DumpServlet that creates a session and dumps basic details about the request:
A WebAppContext is an extension of a ServletContextHandler that uses the standard layout and web.xml to configure the servlets, filters and other features from a web.xml and/or annotations. The following OneWebApp example configures the Jetty test webapp. Web applications can use resources the container provides, and in this case a LoginService is needed and also configured:
The typical way to configure an instance of the Jetty server is via
jetty.xml and associated configuration files. However
the Jetty XML configuration format is just a simple rendering of what you can
do in code; it is very simple to write embedded code that does
precisely what the jetty.xml configuration does. The LikeJettyXml
example following renders in code the behaviour obtained from the