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...)
 
m
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.
+
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.
  
 
| 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 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.
  
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.
+
''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:
  
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.
+
* The ''ContextProvider'' finds and provides webapps based on the existence of context.xml files in the ${jetty.home}/contexts directory
 +
* The ''WebAppProvider'' which finds and provides webapps based on the existence of war files or webapp directories within the ${jetty.home}/webapps directory.   
  
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.
+
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.
  
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.
+
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 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, 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.
 +
 
 +
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.
  
 
}}
 
}}

Revision as of 13:15, 28 April 2011



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.

Feature

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.

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:

  • The ContextProvider finds and provides webapps based on the existence of context.xml files in the ${jetty.home}/contexts directory
  • The WebAppProvider which finds and provides webapps based on the existence of war files or webapp directories within the ${jetty.home}/webapps directory.

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.

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 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, 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.

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.