Version: 9.4.12.v20180830
Version: 9.4.12.v20180830 |
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 for sponsored feature development
Jetty is built around an extensible Deployment Manager architecture complete with formal LifeCycle for Web Applications going through it.
For Jetty to serve content (static or dynamic), a ContextHandler needs to be configured and added to Jetty in the appropriate location.
A pluggable DeploymentManager exists to make this process easier.
The Jetty distribution contains example DeploymentManager configurations to deploy WAR files found in a directory to Jetty, and to deploy Jetty context xml files into Jetty as well.
The DeploymentManager is the heart of the typical webapp deployment mechanism; it operates as a combination of an Application LifeCycle Graph, Application Providers that find and provide Applications into the Application LifeCycle Graph, and a set of bindings in the graph that control the deployment process.
Before Jetty deploys an application, an AppProvider identifies the App and then provides it to the DeploymentManager.
The main AppProvider with the Jetty distribution is the WebAppProvider.
The core feature of the DeploymentManager is the Application LifeCycle Graph.
The nodes and edges of this graph are pre-defined in Jetty along the most common actions and states found. These nodes and edges are not hardcoded; they can be adjusted and added to depending on need (for example, any complex requirements for added workflow, approvals, staging, distribution, coordinated deploys for a cluster or cloud, etc.).
New applications enter this graph at the Undeployed node, and the java.lang.String DeploymentManager.requestAppGoal(App,String) method pushes them through the graph.
A set of default AppLifeCycle.Bindings defines standard behavior, and handles deploying, starting, stopping, and undeploying applications.
If desired, custom AppLifeCycle.Bindings can be written and assigned anywhere on the Application LifeCycle graph.
Examples of new AppLifeCycle.Binding implementations that can be developed include:
There are four default bindings:
StandardDeployer — Deploys the ContextHandler into Jetty in the appropriate place.StandardStarter — Sets the ContextHandler to started and start accepting incoming requests.StandardStopper — Stops the ContextHandler and stops accepting incoming requests.StandardUndeployer — Removes the ContextHandler from Jetty.
A fifth, non-standard binding, called DebugBinding, is also available for debugging reasons; it logs the various transitions through the Application LifeCycle.
In addition to the LifeCycle bindings discussed above, there is also the GlobalWebappConfigBinding which, when added to the DeploymentManager will apply an additional configuration XML file to each webapp that it deploys.
This can useful when setting server or system classes, or when defining override descriptors.
This configuration XML file will be in addition to any context XML file that exists for the webapp; it will be applied after any context XML files but before the webapp is started.
The format for the XML file is the same as any context XML file and can be used to same parameters for a webapp.
To use this binding, you can either modify the existing jetty-deploy.xml which comes with the Jetty distribution (be sure to copy it to your $JETTY_BASE/etc directory first), or by creating a new module file which calls to an additional XML file.
<Call name="addLifeCycleBinding">
<Arg>
<New class="org.eclipse.jetty.deploy.bindings.GlobalWebappConfigBinding" >
<Set name="jettyXml"><Property name="jetty.home" default="." />/etc/global-webapp-config.xml</Set>
</New>
</Arg>
</Call>The WebAppProvider is used for the deployment of Web Applications packaged as WAR files, expanded as a directory, or declared in a Jetty Deployable Descriptor XML File. It supports hot (re)deployment.
The basic operation of the WebAppProvider is to periodically scan a directory for deployables.
In the standard Jetty Distribution, this is configured in the ${jetty.home}/etc/jetty-deploy.xml file.
<?xml version="1.0"?>
<!DOCTYPE Configure PUBLIC "-//Jetty//Configure//EN" "http://www.eclipse.org/jetty/configure_9_3.dtd">
<Configure id="Server" class="org.eclipse.jetty.server.Server">
<Call name="addBean">
<Arg>
<New id="DeploymentManager" class="org.eclipse.jetty.deploy.DeploymentManager">
<Set name="contexts">
<Ref refid="Contexts" />
</Set>
<Call id="webappprovider" name="addAppProvider">
<Arg>
<New class="org.eclipse.jetty.deploy.providers.WebAppProvider">
<Set name="monitoredDirName"><Property name="jetty.home" default="." />/webapps</Set>
<Set name="defaultsDescriptor"><Property name="jetty.home" default="." />/etc/webdefault.xml</Set>
<Set name="scanInterval">1</Set>
<Set name="extractWars">true</Set>
</New>
</Arg>
</Call>
</New>
</Arg>
</Call>
</Configure>The above configuration will create a DeploymentManager tracked as a Server LifeCycle Bean, with the following configuration.
id="Contexts" found in the ${jetty.home}/etc/jetty.xml file, which itself is an instance of ContextHandlerCollection.The file path or URL to the directory to scan for web applications.
Scanning follows these rules:
".") are ignored.".d" are ignored."CVS" and "CVSROOT" are ignored.*.war files are considered automatic deployables.*.xml files are considered context descriptor deployables.root.war/ROOT.war or directory name root/ROOT will result in a deployment to the "/" context path./WEB-INF/web.xml is applied.
The ${jetty.home}/etc/webdefault.xml that comes with the Jetty distribution controls the configuration of the JSP and Default servlets, along with MIME-types and other basic metadata.monitoredDirName for changes: new contexts to deploy, changed contexts to redeploy, or removed contexts to undeploy.