Hi Hong：
Sorry about my delay reply to this document, I have updated the one pager
during the last few days.
1. Section 3.1 Problem Area: I like all the new contents you added here,
but I feel most of the contents here probably belong in other sections: some
of them probably in Technical Details section, and some of them probably in
Out Of Scope section (the http use cases). The problem we are trying to
solve here is similar to what you put in the Justifications section, is 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.
I have moved some of the contents to the other section and modify the
problem area section.
2. Section 4.1 Technical Details:
a. Section 4.1.1.1 DAS Mode: the target should only be the DAS
server (the default "server") and not cluster.
b. Section 4.1.1.2/4.1.1.3 Standalone Instance Mode/Cluster Mode:
standalone instance should be handled similarly as cluster. For both
targets, based on what we previously discussed, the deployuri command will
handle things between client and DAS (similar to what you described in the
DAS mode section) to handle the file download etc during deployment, and for
between DAS and standalone instance/cluster part, the existing _deploy
command should be used and deployuri should not be replicated. Like
DeployCommand which only executes on DAS, the DeployURICommand should only
be executed on DAS also. Once the DAS part of the deployment finishes, the
code path should be exactly the same for a URI param and a File param.
I have converge the section of cluster and instance into one section: I
have list some of the syntax about deploying the application to the DAS or
cluster.
3. Section 4.1.3 Use Cases:
a. Section 4.1.3.1: I am not too sure how the first sentence fit in
the context (For the command of deployuri to be applied, there must be an
active version of the application), maybe you could clarify.
What I have write here means it will not download the application when the
suffix of the URI is not .jar, .war, .ear, .rar. Nowadays, there’s no api
judge the application type from the URI. (I have found the
HttpURLConnection, but it can judge many other type of file except the type
whether it is end with .jar, .war, .rar, .war). Of course, if it is a
useless URI, the action will fail and we will offer some error messages.
b. I noticed there are some use cases you listed here are the ones
that we don't plan to support, in that case we should probably separate the
use cases into two groups, one is supported use cases and one is not
supported use cases (where appropriate error message will be provided).
Ok, I have changed it already.
4. Section 4.3 In Scope: Can you clarify what this meant (The command of
“deployuri” will accept the URI as a path to deploy the application which
is still not been downloaded. It will skip the step about downloading the
application during the Internet)?
I mean the application can be downloaded automatic during the deployuri
command.
5. Section 4.5 Interfaces
a. Section 4.5.1 Public Interfaces: you should document the syntax
of the new deployuri command here with the options/operand.
I have list some option about deployuri in section 4.5.1 Public
Interfaces, I’m not so sure whether my list of options is enough, What I
think is that nearly all of the options support in deploy command should be
support when it comes to the deployuri commad.
6. Section 4.7 Admin/Config Support: as we talked previously, you should
add the plan for console here (plan to support or not support for initial
release).
Ok, I think we should support this feature on the console.
7. Section 4.10 Packaging, Delivery & Upgrade: you mentioned there will
be some changes to the RemoteRestAdminCommand, what are the changes you are
thinking about?
The codes in RemoteRestAdminCommand I prepare to change is to add the
function about analysis the URI and download the application.(Or I will
create another java class to add the feature in admin module)
8. Section 6.1 Project Availability: as we discussed previously, this is
now too late for Java EE 7 release, you can put the date as TBD for now.
Ok.
BTW: some of the reasons why I didn’ t support the function about deploy as
a directory module when it comes to the http protocol and ftp protocol is
because it is hard to code this and it will influence the capability when
the GF is running.
I hope if you can understand my human schedule about this new feature.
Thanks.
Jeremy
From: Hong Zhang [mailto:hong.hz.zhang_at_oracle.com]
Sent: Wednesday, February 27, 2013 5:03 AM
To: dev_at_glassfish.java.net
Subject: Re: (review dependency) one pager about GLASSFISH-12699
Hi, Jeremy
Thanks for updating the one pager based on the previous comments and
adding lots of the details to this new version! Please see my additional
comments below.
1. Section 3.1 Problem Area: I like all the new contents you added here,
but I feel most of the contents here probably belong in other sections: some
of them probably in Technical Details section, and some of them probably in
Out Of Scope section (the http use cases). The problem we are trying to
solve here is similar to what you put in the Justifications section, is 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.
2. Section 4.1 Technical Details:
a. Section 4.1.1.1 DAS Mode: the target should only be the DAS
server (the default "server") and not cluster.
b. Section 4.1.1.2/4.1.1.3 Standalone Instance Mode/Cluster Mode:
standalone instance should be handled similarly as cluster. For both
targets, based on what we previously discussed, the deployuri command will
handle things between client and DAS (similar to what you described in the
DAS mode section) to handle the file download etc during deployment, and for
between DAS and standalone instance/cluster part, the existing _deploy
command should be used and deployuri should not be replicated. Like
DeployCommand which only executes on DAS, the DeployURICommand should only
be executed on DAS also. Once the DAS part of the deployment finishes, the
code path should be exactly the same for a URI param and a File param.
3. Section 4.1.3 Use Cases:
a. Section 4.1.3.1: I am not too sure how the first sentence fit in
the context (For the command of deployuri to be applied, there must be an
active version of the application), maybe you could clarify.
b. I noticed there are some use cases you listed here are the ones
that we don't plan to support, in that case we should probably separate the
use cases into two groups, one is supported use cases and one is not
supported use cases (where appropriate error message will be provided).
4. Section 4.3 In Scope: Can you clarify what this meant (The command of
“deployuri” will accept the URI as a path to deploy the application which
is still not been downloaded. It will skip the step about downloading the
application during the Internet)?
5. Section 4.5 Interfaces
a. Section 4.5.1 Public Interfaces: you should document the syntax
of the new deployuri command here with the options/operand.
6. Section 4.7 Admin/Config Support: as we talked previously, you should
add the plan for console here (plan to support or not support for initial
release).
7. Section 4.10 Packaging, Delivery & Upgrade: you mentioned there will
be some changes to the RemoteRestAdminCommand, what are the changes you are
thinking about?
8. Section 6.1 Project Availability: as we discussed previously, this is
now too late for Java EE 7 release, you can put the date as TBD for now.
Thanks,
- Hong
On 2/26/2013 3:08 AM, lvsongping wrote:
Hi, Hong, Tim:
Cc: GF developers:
I have renew my one pager about GLASSFISH-12699 and write down some
detailed situation about deploying the application by accepting the path as
URI.
Maybe some of my content I have written into the one pager will not as good
as you think, if it is not enough, I want you give some
useful tips to me.
The related JIRA URL are as follows:
http://java.net/jira/browse/GLASSFISH-12699
Best regards
Jeremy