GlassFish - World's first Java EE 7 Application Server


Production DeployUri One Pager

1. Introduction

1.1. Project/Component Working Name:

Support a new command to deploy the application by accepting the path as URI

 

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

Jeremy_Lv: lvsongping@cn.fujitsu.com

 

1.3. Date of This Document:

02/26/2013

 

2. Project Summary

2.1. Project Description:

Support a new command to deploy the application by accepting the path as URI

 

2.2. Risks and Assumptions:

This feature is done by external contributor Jeremy and there is certain risk associated with external contributors.

 

3. Problem Summary

3.1. Problem Area:

 

To allow user deploy with a URI directly instead of doing a two-step process, obtain the file associated with the URI and then deploy.

 

3.2. Justification:

The feature is more of ease of use, a convenience for avoiding a separate download step for an application that is available at a URI and support the feature to deploy the application exists on the host that is running the DAS.

 

4. Technical Description:

4.1. Details:

4.1.1. Expected behavior

All the URI related logic (resolving the URI, downloading the relevant file) are handled by the the deployuri command running in the DAS. No changes for the admin client side and no changes for the command executed in the cluster/standalone instance.

 

4.1.1.1. DAS mode

 

With production deployuri feature, the user will be able to deploy the application by accepting the path as a URI type. Some of the situations that will be realized in the DAS mode will be as follows:

A)  (file:// syntax):  In the deployuri command, it will support the feature to deploy the application exists on the host that is running the DAS. It means the local admin client will accept the option and then the remote server will handle the process and deploy the application which exists on the same host of the running server just as deploy command.

B)  Deploy the remote application to the local server: This syntax is aimed at the http:// syntax and ftp:// syntax, the local server side will download the remotely application to the local temp directory(i.e:　GF_HOME/domains/domain1/config), then the local server side will accept the temp file’s address and handle the process similar to the deploy command to deploy the application to the local server.

C)  Deploy the remote application to the remote server: When the application server is remotely and we need to specify the host address, the remote server side will download the application to the remote temp directory first and then the remote server side will handle the process similar to the existing deploy command.

 

4.1.1.2. Standalone Instance mode/cluster mode

 

The deployuri command support the application to be deployed to the instance/cluster, there exist many situations as follows:

A)   (file:// syntax):  In the deployuri command, it will support the feature to deploy the application exists on the same host of the server which delivered the instance/cluster. It means the local admin client will accept the option but the server side will download the application to the temp directory on the server side. Finally the instance and cluster which is delivered by the server will handle the deployment logical to make sure the application will be deployed to the related cluster/instance.

B)   Deploy the remote application to the instance/cluster delivered by local server: Firstly, the local server side will handle the URI and download the application to the local temp directory. Secondly, the local server side will get the proper temp address and deploy the application to the local server. Finally, the local server will deliver the application to the related instance/cluster to make sure the application to be deployed to the instance.

C)   Deploy the remote application to the instance/cluster delivered by remote server: Firstly, the remote server side will handle the URI and download the application to the remote temp directory. Secondly, the remote server side will get the proper temp address and deploy the application to the remote server. Finally, the remote server will deliver the application to the related instance to make sure the application to be deployed to the instance/cluster.

 

4.1.2. Restricted features

  • --upload: The option of --upload is only support to the file syntax.
  • We needn’t support the proxy option because it can be set into the domain.xml if any users need to set it.

 

4.1.3. Reason why support a new command

A)   As the original syntax about deploy command should be support, It is hard to reuse it to declare a command parameter which will both support the File and URI. It is because the file path can only accept one type of parameter.

B)   The new command will keep things simple. It doesn’t need to change any codes related to the deploy command. We can define a new type of command parameter to support the URI syntax.

 

4.1.4. Support use case examples

4.1.4.1. Context of examples

 

For the command of deployuri to be applied, there exist some tips for the syntax as follows:

  • The URI resource of the application must be exists. (When it comes to the )
  • The suffix about the URI must be ended with the .jar, .war, .ear or .rar to make sure the application can be downloaded to the temp dist exactly. (This situation is only related to the http protocol and ftp protocol)
  • It will support the application to be deployed as directory when it comes to the file:// syntax.
$ asadmin deployuri --host host_address file://e:/test_sample1.war
$ asadmin deployuri　 file:/e:/test_sample1.war
$ asadmin deployuri　---host host_address　 file:/e:/test_dir/apps
$ asadmin deployuri ftp://username:password@host:21/test.war
$ asadmin deployuri   http://java.net/jira/secure/attachment/50467/test_sample1.war
$ asadmin deployuri  --host host_address  -target instance1 file:/e:/test.war
$ asadmin deployuri ---host host_address  --target instance1   ftp://username:password@host:21/test.war
$ asadmin deployuri  ---host host_address  --target cluster1   http://java.net/jira/secure/attachment/50467/test_sample1.war
 

4.1.5. Not support use case examples

4.1.5.1. Context of examples

$ asadmin deployuri  http://dldx.csdn.net/fd.php?i=271450501666412&s=35428f4bec874a3f4124a14beb2ec986

As the suffix String about the above http address is not end with .jar, .war, .ear or .rar, I think some of the error messages should be thrown out to the user when it comes to this situation.

 

4.2. Bug/RFE Number(s):

https://github.com/javaee/glassfish/issues/12699

 

4.3. In Scope:

The deployuri command is able deploy most of the application which path is specified as file:// syntax, http protocol and ftp protocol.

 

4.4. Out of Scope:

 

4.4.1. Http protocol

1). When it comes to the http protocol, there exist many situations as follows:

A)   I think it is unreasonable to support two options like username and password, we should offer some friendly messages to the user under this situation. When we got the URI address base on the http protocol but we can’t download the application from the outside website because the website needs some user certification, it is hard and illegal to pass the username and password from the GF admin client or server to the other website’s database in a common situation.

B)     When the suffix about the offered URI is not end with .jar, .war or .ear. I think we should offer some error messages to this situation because there’s no JDK to analysis these file types according to http protocol.(As the HttpURLConnection can judge other content type except .jar, .war, .ear or .rar).

C)   We don’t support the application deployed as a directory module when it comes to this situation.

 

4.4.2. Ftp protocol

When it comes to the ftp protocol, there exist situations as follows: 

A)   It is no need to define two options as username and password, it is because the standard about ftp will be likeftp://username:password@host:port/filename, we can divided it into pieces to make sure we can connect to the ftp server and download the application to our local temp directory.

B)   We don’t support the application deployed as a directory module when it comes to this situation.

 

4.5. Interfaces:

4.5.1 Public Interfaces

 

The command of deployuri will have the same options as the deploy command with exception of option --upload. (As the option of --upload is only support when the type of the path is File syntax.).

 

4.5.2 Private Interfaces:

 

None.

 

4.5.3 Deprecated/Removed Interfaces:

 

None.

 

4.6. Doc Impact:

Update man pages for the new/modified CLI commands

Application Deployment Guide/Developer Guide for new features

 

4.7. Admin/Config Impact:

CLI:

  • Support a new command to accept the type of the path as a URI.

Admin console:

  • Define a new text area in the deployment page where user can enter the URI address. After the user is finish writing the URI address, we can press the “OK” button and the application can be deployed as URI.

 

4.8. HA Impact:

No impact.

 

4.9. I18N/L10N Impact:

No impact.

 

4.10. Packaging, Delivery & Upgrade:

4.10.1. Packaging

The code could be packaged/delivered in the existing admin module and deployment module. (Presumably in the same module with the deploy command)

 

4.10.2. Delivery

No impact.

 

4.10.3. Upgrade and Migration:

No impact.

 

4.11. Security Impact:

No impact.

 

4.12. Compatibility Impact

No impact.

 

4.13. Dependencies:

4.13.1 Internal Dependencies

None.

 

4.13.2 External Dependencies

If we support the application to be deployed with ftp:// syntax, I think we should inject external jar file called org.apache.commons.net.jar

 

4.14. Testing Impact:

Add new tests (automated) to test production deployuri feature.

 

5. Reference Documents:

 

6. Schedule:

6.1. Projected Availability:

 

  • To Be Determined

 

6.2. Future schedule

  • Maybe there needs to be support a new command called redeployuri in the feature