Jetty: Configuration Overview-What to configure

The previous section describes how to configure Jetty. This section tells you what to configure when using jetty.

Configure Server

The server instance is the central coordination object of the jetty server. It provides service and lifecycle management for all other jetty server components. In the standard jetty announcement, the core server configuration is in the ETC/Jetty. xml file. You can also include other server configurations, including:
1) threadpool
The server instance provides a thread pool where you can configure the maximum number of threads and the minimum number of threads in ETC/Jetty. xml.
2) handlers
The jetty server can have only one handler instance to process HTTP requests. However, a handler can be a container or multiple handler packages. These handler can form a tree. Generally, the root of a branch of the tree is the root of all handler nodes in the leaf node to collaborate to process a request. The default handler tree is set in the ETC/Jetty. xml file, including a context handler set and the default handler. The context handler set selects the next handler through the context path and the path for deploying context handler and web application context. By default, Handler processes requests not processed by other handler and requests that generate the 404 page. Other configuration files can be added? Handler to the handler tree (for example: jetty-rewrite.xml, jetty-requestlog.xml) or configure components to the hot deployment handler (for example: jetty-deploy.xml ).
3) server attributes
The server has a string and a map of objects for other jetty components to associate the specified objects with the server. If these objects implement the lifecycle interface, they will start and stop with the server.
4) server Fields
Server also has some configuration fields, which are set in ETC/Jetty. XML to control the HTTP response date and version number in other tasks.
5) connectors
Server has a collection of ctor, used to receive connections from other protocols supported by HTTP and jetty.
6) Services
Server can have additional service objects, sometimes as attributes, but many others are as lifecycle beans. For example, login services and datasources, you configure them at the server level and inject them into web applications to use them.

Configure connectors

Jetty Server Connector is a network terminal used to receive connections initiated by one or more protocols. This protocol generates requests and/or messages for jetty server. In the standard jetty server release version, the integration of multiple protocols and protocols is supported: jetty-http.xml, jetty-https.xml and jetty-spdy.xml. You usually need to configure:
1) Port
The TCP/IP port listened to by the connector. The corresponding property Jetty. Port (or jetty. TLS. Port) is used. If no port is found, the default value 8080 is used (TLS feels 8443 ).
2) Host
You can configure the host as the host name or IP address. If this parameter is not set or set to 0.0.0.0, the connector listens to all local interfaces. Corresponding property Jetty. Host.
3) idle timeout
When the connection reaches this time, the connection will be closed by the connector, in milliseconds.
4) HTTP configuration
HTTP configuration. The version released by the standard jetty server creates an httpconfiguration In the jetty. xml file, which can be used through the XML ref element in the connector file.
5) SSL context Factory
Assume that the TLS connector type (HTTPS and spdy) is used. You need to configure the SSL context factory to obtain server authentication information.

Configuration Context

The jetty context is a processor. A context handler includes a standard jetty processor or a custom application processor. Configuration is required for all contexts:
1) contextpath
Contextpath is the URL prefix used to identify the context of an HTTP request. For example, assume that a context has a context path/Foo, which processes requests:/Foo,/Foo/index.html,/Foo/BAR/, And/Foo/image.png, however, it does not process requests:/,/other/, or/favicon. ICO. The context whose context path is/is called the root context.
The context can be set by default by the deployer (using the file name as the basis of the context path), encoding, or jetty ioc xml, this can be configured either through the deployer or in the WEB-INF/jetty-web.xml file in the standard web app context.
2) virtualhost
One or more virtual hosts can be configured in the context. A virtual host does not need to be set regardless of the number of network segments, which is equivalent to a service alias that corresponds to an IP address. A service can have multiple aliases. The context with a VM only processes the requests with matching the VM in the request header.
3) classpath
You can set classpath in the context. Standard Web applications specify classpath through the WEB-INF/lib and WEB-INF/classes directories, and can attach rules about the delegate class loading to the pay clasloader.
4) attributes
An attribute is a randomly named object that is associated with a context and is frequently used to transmit objects between a web application and its container. For example, the attribute javax. servlet. Context. tempdir is used to transmit the file instance of the temporary directory allocated to the Web application.
5) resourcebase
Resource base is a directory (or a directory set or URL) that includes static resources of the context. It can be an image or HTML file or a JSP source file. In traditional Webserver, this value is called docroot.

Configure context through API

You can directly call contexthandler to configure the context, for example:

package org.eclipse.jetty.embedded; import org.eclipse.jetty.server.Server;import org.eclipse.jetty.server.handler.ContextHandler; public class OneContext {     public static void main(String[] args) throws Exception {        Server server = new Server(8080);        ContextHandler context = new ContextHandler();        context.setContextPath("/");        context.setResourceBase(".");        context.setClassLoader(Thread.currentThread().getContextClassLoader());        context.setHandler(new HelloHandler());        server.setHandler(context);        server.start();        server.join();    }}

Configure the context through IOC XML

The deployment tool discovery and hot deployment context IOC descriptor. The ioc xml format is as follows:

<?xml version="1.0"  encoding="UTF-8"?><!DOCTYPE Configure PUBLIC     "-//Mort Bay Consulting//DTD Configure//EN"     "http://www.eclipse.org/jetty/configure_9_0.dtd"> <!--  Configure a custom context for serving javadoc as static resources --> <Configure class="org.eclipse.jetty.server.handler.ContextHandler">  <Set name="contextPath">/javadoc</Set>  <Set name="resourceBase"><SystemProperty name="jetty.home" default="."/>/javadoc/</Set>  <Set name="handler">    <New class="org.eclipse.jetty.server.handler.ResourceHandler">      <Set name="welcomeFiles">        <Array type="String">          <Item>index.html</Item>        </Array>      </Set>      <Set name="cacheControl">max-age=3600,public</Set>    </New>  </Set></Configure>

Configure Web Applications

Jetty supports war files and unpackaged Web applications as a specified context. The configuration methods include:
1) Configure standard layout, set resourcebase location (War root folder) and initialize classpath as jar package placed in WEB-INF/lib, classes placed in WEB-INF/classes;
2) Standard WEB-INF/Web. xml defines configuration initialization metrics, filters, Servlets, listeners, security constraints, welcome files and injected resources;
3) The default web. XML (provided by jetty or configured) configures the JSP Servlet and the default servlet for processing static content. The standard web. XML can overwrite the default web. xml;
4) classes in the jar package in the WEB-INF/lib can use the gaze to define additional filters, servlets and listeners;
5) the standard deployment descriptive fragment in the jar package in WEB-INF/lib can define additional initialization metrics, filters, Servlets, listeners, security constraints, welcome files and injected resources;
6) WEB-INF/jetty-web.xml (optional) can include jetty IOC configuration, which is used to configure context and processor Jetty to specify the API.

Set the context path

By default, the deployment tool sets the context path to: assume that you deploy a war file named foobar. war, the context path is/foobar. Suppose you deploy a war file named root. war. The context path is /. Jetty also agrees to set the context path inside the war (war itself) or outside (War deployer.
To set the context path within the war file, you can set the context path using the WEB-INF/jetty-web.xml file:

<?xml version="1.0"  encoding="UTF-8"?><!DOCTYPE Configure PUBLIC     "-//Mort Bay Consulting//DTD Configure//EN"     "http://www.eclipse.org/jetty/configure_9_0.dtd"> <Configure class="org.eclipse.jetty.webapp.WebAppContext">    <Set name="contextPath">/contextpath</Set></Configure>

Alternatively, you can use the IOC File Settings outside the war and specify the war file:

<?xml version="1.0"  encoding="UTF-8"?><!DOCTYPE Configure PUBLIC     "-//Mort Bay Consulting//DTD Configure//EN"     "http://www.eclipse.org/jetty/configure_9_0.dtd"> <Configure class="org.eclipse.jetty.webapp.WebAppContext">  <Set name="war"><SystemProperty name="jetty.home" default="."/>/webapps/test.war</Set>  <Set name="contextPath">/test</Set></Configure>

An example of setting the context path can be seen in $ jetty_home/webapps/test. xml.

Set authentication domain

The authentication methods and domain names of standard Web applications can be set in Web. XML, for example:

...<login-config>  <auth-method>BASIC</auth-method>  <realm-name>Test Realm</realm-name></login-config>...

This example shows that the basic authentication mechanism will be used for the domain name "test realm. However, the standards do not describe how the domain itself is implemented or configured. In jetty, there are several domain implementation methods (called loginservices), the simplest of which is hashloginservice, read username and certificate from a Java property file.
To configure a hashloginservice instance that matches test realm above, the following $ jetty_home/etc/test-realm.xml ioc xml file can be specified in the command line or set in start. ini.

<?xml version="1.0"?><!DOCTYPE Configure PUBLIC "-" "http://www.eclipse.org/jetty/configure_9_0.dtd"><Configure id="Server" class="org.eclipse.jetty.server.Server">    <!-- =========================================================== -->    <!-- Configure Authentication Login Service                      -->    <!-- Realms may be configured for the entire server here, or     -->    <!-- they can be configured for a specific web app in a context  -->    <!-- configuration (see $(jetty.home)/webapps/test.xml for an    -->    <!-- example).                                                   -->    <!-- =========================================================== -->    <Call name="addBean">      <Arg>        <New class="org.eclipse.jetty.security.HashLoginService">          <Set name="name">Test Realm</Set>          <Set name="config"><Property name="demo.realm" default="etc/realm.properties"/></Set>          <Set name="refreshInterval">0</Set>        </New>      </Arg>    </Call>     <Get class="org.eclipse.jetty.util.log.Log" name="rootLogger">      <Call name="warn"><Arg>demo test-realm is deployed. DO NOT USE IN PRODUCTION!</Arg></Call>    </Get></Configure>

This creates and configures loginservice as a server-side aggregate bean. When a web application is deployed as the domain name "test realm", to match the login service, the bean with the domain name will be searched in the server beans.

Web Application Deployment

Jetty can deploy multiple web application formats. jetty deploys context information by scanning the $ {Jetty. Home}/webapps directory.
Context can be one of the following:
1) standard war file (the extension must be ". War ");
2) include the directory of an expanded war file (must include the {dir}/WEB-INF/Web. xml file );
3) directories containing static content;
4) an XML descriptor using jetty XML syntax and configuring a contexthandler instance (such as a webappcontext ).
The new webappprovider will try to avoid repeated deployment during directory scanning by using the following rules:
1) Hidden Files (Files starting with ".") will be ignored;
2) directory names ending with ". d" will be ignored;
3) Assume that a directory has the same base name as the war file (for example, foo/And Foo. war), then the directory will be considered as the decompressed war, and only the war is deployed (the directory that can be decompressed can be reused );
4) Assume that a directory and XML file have the same base name (for example, foo/And Foo. XML), the directory will be considered as the decompressed war, and only XML will be deployed (this directory can be used in its own configuration );
5) if a war file and XML file exist at the same time (such as Foo. War and foo. XML), the war file is considered to be configured by the XML file and deployed only by the XML file.
A context is a contexthandler instance that integrates handlers (such as resource base, Class Loader, and configuration attributes) of other resources that process HTTP requests ). A standard web application is a specific context instance (called webappcontext). It uses standard layout and web. XML to deploy the descriptive descriptor of the configuration context.