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
>