Contact the core Jetty developers at www.webtide.com
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

Using the Deployment Manager

Application Providers
Application LifeCycle Graph
LifeCycle Bindings

For Jetty to serve content (static or dynamic), you need to create a ContextHandler and add it to Jetty in the appropriate place. A pluggable DeploymentManager exists in Jetty 7 and later 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.

Application Providers

Before Jetty deploys an application, an AppProvider identifies the App and then provides it to the DeploymentManager. Two AppProviders come with the Jetty distribution:

  • WebAppProvider –monitors a directory for WebAppProvider *.war files and submits them to the Application LifeCycle Graph for deployment into a context with the same name as the *.war file itself.

  • ContextProvider –monitors a directory for *.xml files, and using the Jetty XML configurator creates a ContextHandler (usually a WebAppContext) for the Application LifeCycle Graph.

Activating both at the same time is possible, but can be confusing because you must take care to either keep both systems deploying mutually exclusive webapps, or align naming conventions of context.xml style files with WAR and webapp directories.

Application LifeCycle Graph

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; you can adjust and add to them depending on your needs (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.

LifeCycle Bindings

A set of default AppLifeCycle.Bindings defines standard behavior, and handles deploying, starting, stopping, and undeploying applications. If you choose, you can write your own AppLifeCycle.Bindings and assign them to anywhere on the Application LifeCycle graph.

Examples of new AppLifeCycle.Binding implementations that you can write include:

  • Validating the incoming application.

  • Preventing the deployment of known forbidden applications.

  • Submitting the installation to an application auditing service in a corporate environment.

  • Distributing the application to other nodes in the cluster or cloud.

  • Emailing owner/admin of change of state of the application.

There are four default bindings:

A fifth, non-standard binding, called Debug Binding, is also available for debugging reasons; It logs the various transitions through the Application LifeCycle.

See an error or something missing?
Contribute to this documentation at Github!