Deployment One Pager For V3 Prelude Release

[

|(TableOfContentstitle='')]

1. Introduction

1.1. Project/Component Working Name:

Deployment

1.2. Name(s) and e-mail address of Document Author(s)/Supplier:

Hong Zhang , Tim Quinn, Jerome Dochez

Email Addresses: hong.zhang@sun.com, timothy.quinn@sun.com, jerome.dochez@sun.com

1.3. Date of This Document:

Initial draft: 06/27/08

Second draft (incorporated comments from internal reviewers): 07/08/08

Third draft (incorporated comments from Bill/asarch): 07/11/08

Final (incorporated comments from user/forum): 07/28/08

2. Project Summary

2.1. Project Description:

Pluggable/extensible deployment framework and general deployment functionality for web modules.

For application management feature (stretch goal for this release), please see the application management one-pager.

2.2. Risks and Assumptions:

The pluggable/extensible deployment framework is currently used to implement the deployment of the web modules. We may discover additional work for the framework as we implement other module types, especially the non-JavaEE module types.

3. Problem Summary

3.1. Problem Area:

We need to provide a pluggable/extensible deployment framework for people to work with new module types. And we need to continue providing the equivalent functionality as in v2 with the new modularized code base.

3.2. Justification:

Make it easier to support new module types, it was fairly difficult to support the sip module type with the v2 code base. Competitive with other OSGi modular implementation. Carry forward existing v2 functionality.

4. Technical Description:

4.1. Details:

The technical details of pluggable/extensible deployment framework are described in the container SPI document.

In the area of providing equivalent deployment functionality for web module as in v2:

The web modules can be deployed through these mechanisms as described in v2.

1. Archive deployment: deploy the web module as an archive.
2. Directory deployment: deploy the web module in a directory format.
3. Dynamic Reloading: redeploy the web module by creating/modifying a special .reload file in the applications repository.
4. Automatic deployment: drop the web archive in the autodeploy directory.
5. Using a deployment plan: deploy a portable archive along with a deployment plan containing application server specific deployment descriptors.

Please refer to v2 doc for the details of the above mechanisms. One exception here, the application's repository for web modules has moved from $DOMAIN_DIR/applications/j2ee-modules to $DOMAIN_DIR/applications. So in the dynamic application reloading case, the path of the .reload file needs to change accordingly.

Deploying through JSR88 is not available in this v3 preclude release. It will be available in the next v3 release (v3.JavaEE6 release).

We continue supporting the same set of operations to manipulate the web module lifecycle as in v2: deploy/redeploy, undeploy, enable, disable. These are the limitations/additions in this release:

1. We only support a subset of the v2 deployment options: name, force (with default value changed to false), contextroot, deploymentplan, upload, virtualserver, precompilejsp, enabled, libraries. Options that are not yet supported are implemented as no-op.
2. A new redeploy command is added which is equivalent to deploy --force=true for a previously-deployed application. Redeploy supports the same options and argument as the deploy command. The redeploy command's "path" option is optional for directory redeployment. The detail of the redeploy command will be documented in the man page.

HTTP based deployment functionality

In addition to the existing interfaces of admin cli and admin console, we also provide the HTTP interface for deployment.

The v3 overview one-pager describes HTTP interface to GlassFish administration at a high level.

Specifically for deployment, following functionalities are available through HTTP interface: deploy/undeploy/redeploy/enable/disable.

The http request will be a URL consisting of a prefix

"/__asadmin"

http://localhost:8080/__asadmin/deploy?contextroot=bar&path=%2Fusr%2Flocal%2Ffoo.war

The http response can be in different forms based on http request "User-Agent" header. For example, it will be in a Manifest form when the header is set to a string starting with "hk2". The http response will contain the command execution result, and the error messages/exceptions in case of failure.

4.2. Bug/RFE Number(s):

Issue 4103

4.3. In Scope:

Deployment functionality of the web modules and other scripting type applications, with the respective teams building modules to support those module types using the pluggable deployment framework.

4.4. Out of Scope:

Deployment functionality of other module types. Container developers can build their own container types and deploy applications to them, as described in the container SPI document.

4.5. Interfaces:

4.5.1 Exported Interfaces

The pluggable/extensible deployment framework related interfaces are described in the container SPI document.
Stability: uncommitted

In admin cli deploy command "asadmin deploy", the default value of the "force" option has changed from "true" to "false".
The change for the default value of the "force" option was made to prevent user from overwriting the original application accidentally.
Stability: uncommitted

A new admin cli command "asadmin redeploy" has been added.
Stability: committed

HTTP based deployment interfaces.
Stability: uncommitted

4.5.2 Imported interfaces

N/A

4.5.3 Other interfaces (Optional)

The internal applications repository layout: the applications repository for web module has moved from $DOMAIN_DIR/applications/j2ee-modules to $DOMAIN_DIR/applications. This change was made to simplify the implementation, avoid unnecessary code branching. Also users will have one uniform place to look for all types of application regardless of the module type.
Stability: committed (as-ccc approved)

The domain.xml: we use a generic "application" element to represent any module, including a web module, instead of the "web-module" element.
Stability: uncommitted

4.6. Doc Impact:

Deployment guide, Admin reference, CLI man pages

4.7. Admin/Config Impact:

New "application" element in the domain.xml subsumes the role of the "web-module" element.

4.8. HA Impact:

None

4.9. I18N/L10N Impact:

No changes from v2.

4.10. Packaging & Delivery:

N/A.

4.11. Security Impact:

No changes from v2.

4.12. Compatibility Impact

The applications repository layout change might impact upgrade depending on the upgrade mechanism we choose.
User scripts that currently leverage the dynamic reload functionality will need to be corrected to reflect the new repository layout.
User scripts that depend on the default behavior of the v2 deploy subcommand may need to be corrected. For example, to adapt to the new default value of the "force" option.

4.13. Dependencies:

Admin infrastructure functional spec.

5. Reference Documents:

Application management one-pager

Container SPI document

V3 overview one-pager

6. Schedule:

6.1. Projected Availability:

The fall '08 release of v3 Prelude.