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

From Eclipsepedia

< Jetty‎ | Feature
Jump to: navigation, search
(New page: {{Jetty Feature | introduction = Jetty provides capability to deploy an arbitrary context or web application by monitoring a directory for changes. If a web application or a context descri...)
 
(7 intermediate revisions by 2 users not shown)
Line 1: Line 1:
 
{{Jetty Feature
 
{{Jetty Feature
 
| introduction =
 
| introduction =
Jetty provides capability to deploy an arbitrary context or web application by monitoring a directory for changes. If a web application or a context descriptor is added to the directory, a new context will be deployed. If a context descriptor is touched/updated then it's context will be stopped, reconfigured and redeployed. If a context descriptor is removed, then it's context will be stopped and removed from the server.
+
In order for Jetty to serve content (static or dynamic), you need to create a [http://download.eclipse.org/jetty/stable-7/apidocs/org/eclipse/jetty/server/handler/ContextHandler.html ContextHandler] and add it 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 =
  
Deploy Manager is the heart of the webapp deployment mechanism, it is responsible for the lifecycle of an application through the phases of deployment.
+
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 that control the deployment process.
  
In essence it is a graph that is pre-populated with standard edges/nodes.  Alone these edges/nodes are useless so we have the ability to bind an implementation (of the DeployManager) to a specific node.  There are four default bindings, 'deploying', 'starting', 'stopping', and 'undeploying'.  There is a fifth that is provided which is not a part of the standard process called the DebugBinding.
+
[[Image:Jetty_DeployManager_DeploymentManager_Roles.png]]
  
Now a graph with bindings is nothing without a way for (web)apps to enter the lifecycle. And that is what the AppProviders are.  You can have as many AppProvider implementations as you like registered with the deployment manager mechanism.  By default we have two provided with jetty, the ContextProvider finds and provides webapps based on the existence of context.xml files in the ${jetty.home}/contexts directory and the WebAppProvider which finds and provides webapps based on the existence of war files or webapp directories within the ${jetty.home}/webapps directory.  Having both active at the same time is possible, but can be confusing as you must take care to either keep both systems deploying mutually exclusive webapps or by aligning naming conventions of context.xml style files with war/webapp directories.
+
=== Application Providers ===
  
The lifecycle graph (the collection of edges and nodes) can be modified at startup.  An implementor can insert new edges and nodes where they choose but it's quite an advanced usage.  Normal use cases will be fine with the existing mechanism, although if there is a requirement for preprocessing 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. Regardless, only those working on advanced deployments, vetting of content, modification of webapps prior to deployment should really concern themselves with extending the deployment manager in this way.
+
Before Jetty deploys an application, an [http://download.eclipse.org/jetty/stable-7/apidocs/org/eclipse/jetty/deploy/AppProvider.html AppProvider] identifies the App and then provides it to the Deployment Manager. Two AppProviders come with the Jetty distribution:
  
Looking at the graphs, if a new app is submitted to the lifecycle by an App Provider, it automatically enters the graph at “Undeployed.” There is a request to the DeploymentManager to move that app to 'Started' state. (this is the default behavior of jetty atm). The app is found at "Undeployed", and a breadth-first search is performed on the graph to see 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 if it reaches the goal node, or if an exception is thrown.
+
*'''[http://download.eclipse.org/jetty/stable-7/apidocs/org/eclipse/jetty/deploy/providers/WebAppProvider.html WebAppProvider]'''–monitors a directory for <tt>*.war</tt> files and submits them to the Application LifeCycle Graph for deployment into a context with the same name as the <tt>*.war</tt> file itself. Also see [[Jetty/Feature/WebAppProvider]]
 +
 
 +
*'''[http://download.eclipse.org/jetty/stable-7/apidocs/org/eclipse/jetty/deploy/providers/ContextProvider.html ContextProvider]'''–monitors a directory for <tt>*.xml</tt> files, and using the Jetty Xml configurator creates a ContextHandler (usually a WebAppContext) for the Application LifeCycle Graph. Also see [[Jetty/Feature/ContextProvider]]
 +
 
 +
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.
 +
 
 +
=== 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:Jetty_DeployManager_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; 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 [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 pushes them through the graph.
 +
 
 +
=== LifeCycle Bindings ===
 +
 
 +
A set of default [http://download.eclipse.org/jetty/stable-7/apidocs/org/eclipse/jetty/deploy/AppLifeCycle.Binding.html AppLifeCycle.Bindings] defines standard behavior, and handles deploying, starting, stopping, and undeploying applications. If you choose, you can write your own AppLifeCycle.Binding's 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:
 +
* [http://download.eclipse.org/jetty/stable-7/apidocs/org/eclipse/jetty/deploy/bindings/StandardDeployer.html StandardDeployer]–Deploys the ContextHandler into Jetty in the appropriate place.
 +
* [http://download.eclipse.org/jetty/stable-7/apidocs/org/eclipse/jetty/deploy/bindings/StandardStarter.html StandardStarter]–Sets 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]–Stops the ContextHandler and stop accepting incoming requests.
 +
* [http://download.eclipse.org/jetty/stable-7/apidocs/org/eclipse/jetty/deploy/bindings/StandardUndeployer.html StandardUndeployer]–Removes the ContextHandler from Jetty.
 +
 
 +
[[Image:Jetty_DeployManager_DefaultAppLifeCycleBindings.png]]
 +
 
 +
A fifth, non-standard binding, called ''DebugBinding'', is also available for debugging reasons; It logs the various transitions through the Application LifeCycle.
  
 
}}
 
}}

Revision as of 10:03, 28 August 2012



Contents

Introduction

In order 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 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 that control the deployment process.

Jetty DeployManager DeploymentManager Roles.png

Application Providers

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

  • WebAppProvider–monitors a directory for *.war files and submits them to the Application LifeCycle Graph for deployment into a context with the same name as the *.war file itself. Also see Jetty/Feature/WebAppProvider
  • ContextProvider–monitors a directory for *.xml files, and using the Jetty Xml configurator creates a ContextHandler (usually a WebAppContext) for the Application LifeCycle Graph. Also see Jetty/Feature/ContextProvider

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.

Jetty DeployManager 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; 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.Binding's 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:

Jetty DeployManager DefaultAppLifeCycleBindings.png

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