[GLASSFISH-12699] Allow deploy command to accept URI Created: 17/Jul/10  Updated: 21/Jan/13

Status: Open
Project: glassfish
Component/s: deployment
Affects Version/s: 3.1
Fix Version/s: not determined

Type: Improvement Priority: Major
Reporter: Sanjeeb Sahoo Assignee: Hong Zhang
Resolution: Unresolved Votes: 0
Labels: None
Σ Remaining Estimate: Not Specified Remaining Estimate: Not Specified
Σ Time Spent: Not Specified Time Spent: Not Specified
Σ Original Estimate: Not Specified Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Attachments: Zip Archive GLASSFISH-12699_REVISED_SOURCE.zip     Text File pathToUri_patch.txt    
Sub-Tasks:
Key
Summary
Type
Status
Assignee
GLASSFISH-19497 Can't get the proper path when deploy... Sub-task Closed Hong Zhang  
GLASSFISH-19529 The asadmin client should support the... Sub-task Resolved Tom Mueller  
Issuezilla Id: 12,699

 Description   

Currently deploy, redeploy commands accept a file path. It will be nice if they
accept a URI instead. I am attaching a patch which is an attempt to address
this, but I don't think it is complete. Any way, if someone wants to take a stab
at this issue, the patch may come handy.



 Comments   
Comment by Sanjeeb Sahoo [ 17/Jul/10 ]

Created an attachment (id=4587)
Patch generated against svn rev #38356

Comment by Hong Zhang [ 17/Jul/10 ]

add tim to CC, tim is more familiar with this part

Comment by Tom Mueller [ 06/Mar/12 ]

Bulk update to change fix version to "not determined" for all issues still open but with a fix version for a released version.

Comment by Jeremy_Lv [ 18/Dec/12 ]

Dear Hong, Sahoo:
I have updated the Sahoo's patch and have this new feature accomplished. But what I have revised is only can be used for deploying the applications in the local space.
i.e:asadmin deploy file:/e:/test_sample1.war(also can be useful about the operation of redeployment)

I have attached the revised source to the JIRA, please review my modification.

BTW: If we need to implement the operation about deploying the application in the Internet(i.e:deploy as http,ftp,https), we can discuss about this scenario first before I have it implemented.
i.e:(asadmin deploy http://http://java.net/jira/secure/attachment/50467/test_sample1.war)

Best Regards
-Jeremy

Comment by Hong Zhang [ 18/Dec/12 ]

Jeremy: thanks for looking into this enhancement and continuing to contribute to GlassFish!

Some comments from my initial look at the changes:

1. When a command line option is File type and annotated with @Param, the admin infrastructure will upload the file from local machine to remote machine. With the changes in DeployCommandParameters, can you make sure the cluster scenario still work as expected, the file will get uploaded as expected? I saw there are changes in MapInjectionResolver which probably take care of this, but want to double check things still work as expected for cluster scenario.

2. Can you try the server restart scenario to make sure things are working as expected there also (deploy application, restart server, and see if application is loaded properly during server start up and can be accessed afterwards)? This is a pretty significant change and I want to make sure there is no regression to the existing scenarios.

3. Run deployment dev tests in PE and EE mode and also run ejb dev tests.

4. Add some new tests in the deployment dev tests to cover the new scenario and enable these tests for both PE and EE mode.

5. The admin related changes (for example, MapInjectionResolver) need to be reviewed by the admin team. We can write to Tom Mueller about this after we make sure the various scenarios are working ok.

And yes we can have further discussions if we decide to expand the feature to support internet protocols.

Comment by Jeremy_Lv [ 09/Jan/13 ]

[Latest investigation]
The changes of mine to support the scenario about 12699 makes the original scenario about deploying the application as File(only deploy the application as relative path) doesn't work...

After I look into the code, I found the value in EntityParamValueFactoryProvider.java(jersey modules) doesn't get the correct value while deploying the application as relative path in File way(e.g: asadmin deploy test.jar)

value = requestContext.readEntity(rawType, parameter.getType(), parameter.getAnnotations());

the value here should be get the absolute path while it just get the name of the deployed application.

However, it can be deployed successfully as absolute path in File way.

Should the original scenario about deploying the application as File way still be support after it is support the URI?

Comment by Sanjeeb Sahoo [ 09/Jan/13 ]

Existing behavior has to be maintained for compatibility reasons. I think it will be reasonable to support the URI syntax for absolute URIs only. An absolute URI always has a scheme component.

Comment by Jeremy_Lv [ 10/Jan/13 ]

Dear Hong, Sahoo, Tom:
I have a question for you. Should the new feature about deploying the application accept the URI instead of File or accept the URI syntax without any changes about File syntax?

Comment by Jeremy_Lv [ 10/Jan/13 ]

After some of my investigation, I found something different between the two definations as follows:
Sample1:

 
    @Param(primary=true) 
    public File path; 
    public File getPath() { 
      return path; 
    } 

Sample2:

 
    private File path; 
     
    @Param(primary=true) 
    public void setPath(File path) { 
        this.path = path; 
    } 
     
    public File getPath() { 
      return path; 
    } 

When the @Param are defined to declare the method as the Sample2 shows, The value of "DEFAULT" is not correct when deployed as a relative File path. the jersey side get the wrong value of "reqeust" when DeployCommandParameters defined as Sample2.

Comment by Hong Zhang [ 10/Jan/13 ]

We have to continue supporting File path for backward compatibility. If that only allows us to support absolute URI, that's fine. We just need to give a good error message for the unsupported case.

I don't know the details of how the payload works (with injected File param), Tom probably knows more about that to explain why. But you will probably need to write an email to him to get his attention on this as I don't think he is monitoring issues outside of the admin area..

Comment by Tom Mueller [ 14/Jan/13 ]

While looking at the subtask GLASSFISH-19529, I decided to comment on this issue instead.

First, what are the expected semantics for the original request? If the deploy command is invoked with a URI, what is the asadmin client expected to do? For example, is the client expected to fetch the content of the URI and then treat that content the same way it treats a file today? Is the URI supposed to be passed to the server, and then the server is supposed to fetch the content of the URI? A key question is, where does the URI client code execute?

Second, since the original syntax must be supported, how is the command parameter actually declared. If it is a URI (as the subtask requests), is the asadmin client expected to convert a path argument to a URI argument automatically? How is the asadmin client supposed to know that the default URI scheme should be "file://"? Is the implementation to be hardcoded this way, or is it necessary to allow the default scheme to be specified by the command.

Or, is the idea hear to allow the operand to be of varying types depending on what is entered by the user? If it looks like a URI, then just the URI is passed, but if it looks like a path, then a File is passed? What would the @Param declaration for a command look like in this case?

Another option might be to have a "deployuri" command (similar to deploydir) which could have a different declaration for the operand.

If just a URI is to be passed to the server (not the content), and the URI references a local file, how would the server access the file if asadmin is remote from the server?

In summary, the following design options seem feasible:

1) Add a deployuri command for which the operand is a String which is passed to the server and the server resolves the URI. Therefore the URI must be resolvable by the server (can't be a file:// URI to a local file that is remote from the server).

2) Modify the CLI framework so that a File parameter (option or operand) can be specified as a URI. In that case, the asadmin client would resolve the URI and download its content to a temporary file which would then be passed as a File parameter like any other File parameter. This option would require no changes to the deploy command at all. With this option, a file:// URI to a file that is local to asadmin would work when the server is remote, but a file:// URI to a file that is local to the server but not asadmin would not work.

Other more complicated options would be to have some way of having a command option that is either a File or a URI but I haven't specified that design here.

Comment by Sanjeeb Sahoo [ 14/Jan/13 ]

I support option #1. It keeps things simple.

Sahoo

Comment by Jeremy_Lv [ 15/Jan/13 ]

First, what are the expected semantics for the original request? If the deploy command is invoked with a URI, what is the asadmin client expected to do? For example, is the client expected to fetch the content of the URI and then treat that content the same way it treats a file today? Is the URI supposed to be passed to the server, and then the server is surpposed to fetch the content of the URI? A key question is, where does the URI client code execute?

What I have supposed to do is that the client expected to fetch the content of the URI and then treat that content the same way it treats a file today.

Second, since the original syntax must be supported, how is the command parameter actually declared. If it is a URI (as the subtask requests), is the asadmin client expected to convert a path argument to a URI argument automatically? How is the asadmin client supposed to know that the default URI scheme should be "file://"? Is the implementation to be hardcoded this way, or is it necessary to allow the default scheme to be specified by the command.
Or, is the idea hear to allow the operand to be of varying types depending on what is entered by the user? If it looks like a URI, then just the URI is passed, but if it looks like a path, then a File is passed? What would the @Param declaration for a command look like in this case?

What I have revised is to define a path as a URI parameter. Then I will try to convert a path argument to a URI argument when it is excuted in the asadmin client.

All in all, What I have revised is based on the option#2, which is defined a URI parameter and change the File to URI when the application is deployed as a File.

BTW: If we decide to take the option#1, I will look into the logical about deploydir first before I code.

Comment by Jeremy_Lv [ 15/Jan/13 ]

Thanks for Tom's suggestion, After being compare these two options I think the option#1 seems better than option#2.
It seems not diffcult to develop and it is no longer to change codes in CLI.

Comment by Jeremy_Lv [ 15/Jan/13 ]

As the JIRA file system can not work, I have sent my modification by email. please check it.

Comment by Jeremy_Lv [ 21/Jan/13 ]

Hi,All:
As Tom has been suggested, I want to make sure what function should I implement.
Here is my option:
1.Support a new command like "deployuri", The "deployuri" will support the following options
1).--name <name>
2).--contextroot <contextroot>
3).--virtualservers <virtualservers>
4).--libraries <libraries>
5).--force[=<force(default:false)>]
6).--precompilejsp[=<precompilejsp(default:false)>]
7).--verify[=<verify(default:false)>]
8).--retrieve <retrieve>
9).--dbvendorname <dbvendorname>
10).--createtables[=<createtables(default:false)>]
11).--dropandcreatetables[=<dropandcreatetables(default:false)>]
12).--uniquetablenames[=<uniquetablenames(default:false)>]
13).--deploymentplan <deploymentplan>
14).--altdd <altdd>
15).--runtimealtdd <runtimealtdd>
16).--enabled[=<enabled(default:false)>]
17).--generatermistubs[=<generatermistubs(default:false)>]
18).--availabilityenabled[=<availabilityenabled(default:false)>]
20).--asyncreplication[=<asyncreplication(default:true)>]
21).--target <target>
22).--keepreposdir[=<keepreposdir(default:false)>
23).--keepfailedstubs[=<keepfailedstubs(default:false)>]
24).--logreportederrors[=<logreportederrors(default:true)>]
25).--description <description>
26).--properties <properties>
27).--property <property>
28).--type <type>
29).--keepstate[=<keepstate(default:false)>]
30).--lbenabled <lbenabled>
31).--deploymentorder <deploymentorder>
32).--upload[=<upload(default:false)>]
33).?|-help[=<help(default:false)>]

BTW:As the application is deployed as URI, Should we give up the function about --upload? (The original option about --upload is support for File types.)

2.Should I support another command which is used for redeploy the application as URI?(As the description shows)

Notice: As the URI is complex type to use, I think I will support the file:// syntax first.

If someone want to present more options about this improvement, please comments.

Best regards
-Jeremy

Generated at Wed Jun 03 02:32:01 UTC 2015 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.