On 3/8/2013 4:17 AM, lvsongping wrote:
>
> Hi, Hong:
>
> Thanks for your patient reply. I have just change a little in
> this version(in section 4.5.1 Public Interface).
>
Thanks. You don't need to list the options anymore with your current
description.
>
>
> 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.
>
I think it will be ok to take advantage of an existing utility class to
write the logic you need, as long as the utility method is invoked by
DeployURI command executed in DAS and the changes to the utility class
does not affect the existing callers.
Thanks,
- Hong
> 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]
> *Sent:* Wednesday, February 27, 2013 5:03 AM
> *To:* dev_at_glassfish.java.net <mailto: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
>