Hi, Hong:
Thanks for your patient reply. I have just change a little in this
version(in section 4.5.1 Public Interface).
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.
One good point that Tom brought up which I did not communicate clearly
previously is we should not modify the command line framework.to accomplish
this feature. The URI should be resolved by the deployuri command running in
the DAS, i.e., the file should not be downloaded by the client. So this will
be the last major area to make changes in the one pager.
Sorry about my careless for this situation. How about coding the logical of
download operation into the common-util
modules(org.glassfish.common.util.admin.MapInjectionResolver) ? Because I
think the MapInjectionResolver is one of the best position to format the URI
to File syntax.
If It is still not a proper position, I will try to implement it in the
deployment module without change any other modules.
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.
Maybe you can say the command will have the same options as the deploy
command with exception of option x, y, z etc (list differences).
Ok, I will change the sentence.
Thanks
- Hong
From: Hong Zhang [ <mailto:hong.hz.zhang_at_oracle.com>
mailto:hong.hz.zhang_at_oracle.com]
Sent: Wednesday, February 27, 2013 5:03 AM
To: <mailto:dev_at_glassfish.java.net> 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>
http://java.net/jira/browse/GLASSFISH-12699
Best regards
Jeremy