Hi, Jeremy
Thanks for publishing the new version of the one pager! Please see my
comments in line:
On 3/7/2013 3:09 AM, lvsongping wrote:
>
> 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.
>
This part looks good in the new version.
>
>
> 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.
>
>
> 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.
>
Got it..
>
>
> 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.
>
>
Ok, thanks.
>
> 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.
>
Got it.
>
>
> 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).
>
> 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.
>
Ok.
>
>
> 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)
>
Please see my previous comment on not changing the CLI command
framework, so we should not have to modify this class.
>
>
> 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.
>
Ok.
>
> I hope if you can understand my human schedule about this new feature.
>
No worries, we understand you have a full time job besides contributing
to GlassFish! Just contribute whenever/whatever you could and we really
appreciate your past contributions to GlassFish to help GlassFish become
a better product!
Thanks,
- Hong
>
> *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
>