Jump to: navigation, search

Difference between revisions of "Jetty/Feature/Deployment Manager"

< Jetty‎ | Feature
m
Line 1: Line 1:
 
{{Jetty Feature
 
{{Jetty Feature
 
| introduction =
 
| introduction =
Jetty provides capability to deploy an arbitrary context or web application. It begins by monitoring a directory for changes. If you add a web application or a context descriptor to the directory, the Deployment Manager (DM) deploys a new context. If you touch or update a context descriptor, the DM stops its context, reconfigures it, and redeploys it. If you remove a context descriptor, the DM stops its context and removes it from the server.
+
In order for Jetty to serve content (static or dynamic) a [http://download.eclipse.org/jetty/stable-7/apidocs/org/eclipse/jetty/server/handler/ContextHandler.html ContextHandler] must be created and added to Jetty in the appropriate place. A pluggable DeploymentManager exists in Jetty 7 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.  
  
 
| body =
 
| body =
  
The Deployment Manager is the heart of the webapp deployment mechanism; it is responsible for the lifecycle of an application through the phases of deployment. In essence it is a graph pre-populated with standard edges/nodes.  Alone these edges/nodes are useless, but Jetty has the ability to bind an implementation (of the DeployManager) to a specific node. There are four default bindings: ''deploying'', ''starting'', ''stopping'', and ''undeploying''.  A fifth, the ''DebugBInding'', is also provided, but is not a part of the standard process.
+
The Deployment Manager 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 to control the behavior of the deployment process.
  
''AppProviders'' create a way for (web)apps to enter the lifecycle. You can have as many AppProvider implementations as you like registered with the DM mechanism.  By default Jetty provides two:
+
=== App Providers ===
  
* The ''ContextProvider'' finds and provides webapps based on the existence of <tt>context.xml</tt> files in the <tt>${jetty.home}/contexts</tt> directory.
+
Applications that are to eventually become Deployed must first enter be identified by an [http://download.eclipse.org/jetty/stable-7/apidocs/org/eclipse/jetty/deploy/AppProvider.html AppProvider], whose responsibility it is to provide Apps to the DeploymentManager.
* The ''WebAppProvider'' finds and provides webapps based on the existence of WAR files or webapp directories within the <tt>${jetty.home}/webapps</tt> directory.
+
 
 +
There are two AppProvider's that come with the Jetty Distribution.
 +
 
 +
'''[http://download.eclipse.org/jetty/stable-7/apidocs/org/eclipse/jetty/deploy/providers/WebAppProvider.html WebAppProvider]'''
 +
 
 +
The default WebAppProvider can monitor a directory for *.war files and submit them to the Application LifeCycle Graph for deployment into a context with the same name as the *.war file itself.
 +
 
 +
'''[http://download.eclipse.org/jetty/stable-7/apidocs/org/eclipse/jetty/deploy/providers/ContextProvider.html ContextProvider]'''
 +
 
 +
The default ContextProvider can monitor a directory for *.xml files and using the Jetty Xml configurator create a ContextHandler (usually a WebAppContext) to 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 <tt>context.xml</tt> style files with WAR and webapp directories.
 
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 <tt>context.xml</tt> style files with WAR and webapp directories.
  
You can modify the lifecycle graph (the collection of edges and nodes) at startup. You can insert new edges and nodes where you choose, but doing so constitutes quite an advanced use. Normal use cases work well with the existing mechanism, although if there is a requirement to preprocess a webapp to scan for some metadata, or check for some external condition like database accessibility that a particular user installation is highly interested in, you might need to go this route. Regardless, only those working on advanced deployments–vetting content, or modifying webapps prior to deployment–should attempt to extend the DM in this way.
+
=== Application LifeCycle Graph ===
 +
 
 +
The core feature of the DeploymentManager is the [http://download.eclipse.org/jetty/stable-7/apidocs/org/eclipse/jetty/deploy/AppLifeCycle.html Application LifeCycle Graph].
 +
 
 +
[[Image:http://joakim.erdfelt.com/jetty/sites/jetty-deploy/org/eclipse/jetty/deploy/doc-files/AppLifeCycle.png]]
 +
 
 +
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, and can be adjusted and added to depending on need. (Such as any complex need for added workflow, approvals, staging, distribution, coordinated deploys for a cluster or cloud, etc...)
 +
 
 +
New Applications enter this graph at the Undeployed node, and are pushed through the graph via the use of the [http://download.eclipse.org/jetty/stable-7/apidocs/org/eclipse/jetty/deploy/DeploymentManager.html#requestAppGoal(org.eclipse.jetty.deploy.App, java.lang.String) DeploymentManager.requestAppGoal(App,String)] method.
 +
 
 +
=== LifeCycle Bindings ===
 +
 
 +
The responsibility for deploying, starting, stopping, undeploying is handled by a set of default [http://download.eclipse.org/jetty/stable-7/apidocs/org/eclipse/jetty/deploy/AppLifeCycle.Binding.html AppLifeCycle.Binding]'s that define the standard behavior.
 +
 
 +
If you choose to, you can write your own AppLifeCycle.Binding's and assign them to anywhere on the Application LifeCycle graph.
 +
 
 +
Example's of new AppLifeCycle.Binding implementations that could be written:
 +
 
 +
* Validate the incoming Application.
 +
* Prevent the deployment of known forbidden Applications.
 +
* Submit the installation to an Application auditing service in a corporate environment.
 +
* Distribute the Application to other nodes in the cluster or cloud.
 +
* Email owner / admin of change of state of the Application.
 +
 
 +
There are four default bindings:
 +
* [http://download.eclipse.org/jetty/stable-7/apidocs/org/eclipse/jetty/deploy/bindings/StandardDeployer.html StandardDeployer] - will deploy the ContextHandler into Jetty in the appropriate place.
 +
* [http://download.eclipse.org/jetty/stable-7/apidocs/org/eclipse/jetty/deploy/bindings/StandardStarter.html StandardStarter] - will set the ContextHandler to started and start accepting incoming requests
 +
* [http://download.eclipse.org/jetty/stable-7/apidocs/org/eclipse/jetty/deploy/bindings/StandardStopper.html StandardStopper] - will stop the ContextHandler and stop accepting incoming requests.
 +
* [http://download.eclipse.org/jetty/stable-7/apidocs/org/eclipse/jetty/deploy/bindings/StandardUndeployer.html StandardUndeployer] - will remove the ContextHandler from Jetty.
  
When an App Provider submits a new app to the lifecycle, it automatically enters the graph at ''Undeployed''. It sends a request to the DM to move that app to ''Started'' state (the default behavior of Jetty atm). The DM finds the app at ''Undeployed'', and performs a breadth-first search on the graph to discover how to get to ''Started''. It finds the path .... ''Undeployed -> Deploying -> Deployed -> Starting -> Started''. It executes each step of the path, and executes each binding at each step, stopping when it reaches the goal node, or if an exception is thrown.
+
A fifth, non-standard binding, called ''DebugBinding'', is also available for debugging reasons; It will Log the various transitions through the Application LifeCycle.
  
 
}}
 
}}

Revision as of 16:19, 29 June 2011



Introduction

In order for Jetty to serve content (static or dynamic) a ContextHandler must be created and added to Jetty in the appropriate place. A pluggable DeploymentManager exists in Jetty 7 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.

Feature

The Deployment Manager 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 to control the behavior of the deployment process.

App Providers

Applications that are to eventually become Deployed must first enter be identified by an AppProvider, whose responsibility it is to provide Apps to the DeploymentManager.

There are two AppProvider's that come with the Jetty Distribution.

WebAppProvider

The default WebAppProvider can monitor a directory for *.war files and submit them to the Application LifeCycle Graph for deployment into a context with the same name as the *.war file itself.

ContextProvider

The default ContextProvider can monitor a directory for *.xml files and using the Jetty Xml configurator create a ContextHandler (usually a WebAppContext) to 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.

File:Http://joakim.erdfelt.com/jetty/sites/jetty-deploy/org/eclipse/jetty/deploy/doc-files/AppLifeCycle.png

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, and can be adjusted and added to depending on need. (Such as any complex need for added workflow, approvals, staging, distribution, coordinated deploys for a cluster or cloud, etc...)

New Applications enter this graph at the Undeployed node, and are pushed through the graph via the use of the java.lang.String) DeploymentManager.requestAppGoal(App,String) method.

LifeCycle Bindings

The responsibility for deploying, starting, stopping, undeploying is handled by a set of default AppLifeCycle.Binding's that define the standard behavior.

If you choose to, you can write your own AppLifeCycle.Binding's and assign them to anywhere on the Application LifeCycle graph.

Example's of new AppLifeCycle.Binding implementations that could be written:

  • Validate the incoming Application.
  • Prevent the deployment of known forbidden Applications.
  • Submit the installation to an Application auditing service in a corporate environment.
  • Distribute the Application to other nodes in the cluster or cloud.
  • Email owner / admin of change of state of the Application.

There are four default bindings:

  • StandardDeployer - will deploy the ContextHandler into Jetty in the appropriate place.
  • StandardStarter - will set the ContextHandler to started and start accepting incoming requests
  • StandardStopper - will stop the ContextHandler and stop accepting incoming requests.
  • StandardUndeployer - will remove the ContextHandler from Jetty.

A fifth, non-standard binding, called DebugBinding, is also available for debugging reasons; It will Log the various transitions through the Application LifeCycle.