very good example of why deploy --force true by default was a bad
idea, if we had correct deploy --force option we would have the
following
deploy foo --> deploy the foo directory
deploy --force true foo --> redeploy the foo app
redeploy foo --> redeploy the foo app
Jerome
On Mar 14, 2008, at 12:57 PM, Kedar Mhaswade wrote:
> Let me clarify. I am assuming that when you as a user, are deploying
> and
> redeploying an "archive" foo.war", you know the path to foo.war. Thus,
> the command sequence is:
> - asadmin deploy /archives/foo.war
> - asadmin deploy /archives/foo.war => results in foo.war's
> redeployment.
>
> The exact same logic applies to directory deployment (except that we
> have a separate command named "deploydir"):
> - asadmin deploydir /Projects/NB/Foo/web => creates a web-app named
> "web"
> - asadmin deploydir /Projects/NB/Foo/web => results in "web"'s
> redeployment.
>
> So, the consistency is you know precisely what you are (re)deploying
> -- the
> path to the archive or path to the folder where app's contents are.
>
> This was in V2.
>
> I understand that we want to provide deployment based on a "name"
> rather than
> a path, but that is foiled by the following:
>
> It seems, we changed two things in V3. In V3, there is no deploydir
> command and hence, there is no way for the server to know what to
> do on simple : "asadmin deploy foo", whether it is a directory
> deployment
> of a directory called "foo" or directory redeployment of an
> application
> which was deployed as a name "foo" (since, server presumably knows its
> location).
>
> Is it bad to assume that you provide the path to the application you
> are redeploying, (because that's what you provided on initial
> deployment)?
>
> vince kraemer wrote:
>> Kedar,
>> Having users re-enter data that is not necessary (because they have
>> already given that data to the server) is a flaw. It lowers the
>> usability of the CLI.
>> Jerome identified that flaw and implemented a new command
>> (redeploy) to help eliminate it. Since Jerome is an 'architect',
>> one of his charters is to identify flaws in the current product and
>> design solutions to them, before the user community has filed
>> issues about them.
>> He had done his job... and then it seems that his work got
>> undone... for reasons which seem to focus on "our" (Project
>> GlassFish developers) convenience and not user convenience.
>> Note: Our convenience may be a valid reason to defer
>> implementation, if the solution that Jerome was proposing were just
>> at the design stage.
>> vbk
>> Kedar Mhaswade wrote:
>>> Hmmm. I must not be reading those.
>>> In V2, we don't have an *asadmin redeploy* command and no
>>> user has reported this to be a flaw. Why would we want users
>>> to undergo deploy/redeploy/undeploy when deploy/undeploy worked?
>>>
>>> Again, I am talking only w.r.t. "asadmin".
>>>
>>> Jerome Dochez wrote:
>>>> Independently of the --force fate, I think a redeploy command is
>>>> highly desirable as it comes quite naturally to Java EE users
>>>> accustomed to deploy/redeploy/undeploy actions as specified
>>>> everywhere in industry standard docs, books and postings.
>>>>
>>>> Jerome
>>>>
>>>> On Mar 13, 2008, at 9:41 AM, Kedar Mhaswade wrote:
>>>>
>>>>> I thought that the plan of record is till we find the correct
>>>>> default value
>>>>> for --force, it remains true. This was after ccc meeting
>>>>> yesterday.
>>>>>
>>>>> Thus, asadmin deploy foo.war [foodir] followed by asadmin deploy
>>>>> foo.war
>>>>> [foodir] should result in redeployment of the underlying
>>>>> application/module.
>>>>>
>>>>> This means, we should not use "redeploy" command just yet, as
>>>>> "deploy
>>>>> over deploy" is supposed to achieve the same effect.
>>>>>
>>>>> I am not convinced we ought to have a "redeploy" command.
>>>>>
>>>>> Jerome, Bill, please help clarify doubts here.
>>>>>
>>>>> - Kedar
>>>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
>> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>