Hi
how we will handle situation like
run deploy uri and it will deploy to DAS
now next time I want to target the already deployed app to perticular
cluster or server. ?
another one
I want to just deploy to particular cluster or instance, but not on DAS,
do we allow this in any mode(CLI, DAS, deployURI) of deploy operation. ?
Thanks
Gajanan
On 3/8/2013 2:47 PM, 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).
>
>
> 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]
> *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
>
--
"I say the glass is always full- half with air, half with water!" - Modi