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.
Yes. I agree. That is the way it was.
asadmin deploy /archives/foo.war also creates a web-app named foo....
>
> 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).
That is a great catch. So, now we just need to figure out a way to make
it easy for the user to disambiguate their intent, without requiring
that they reenter a full path every time they want to redeploy something.
> 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)?
I have a bit of trouble parsing this question.
I think it is bad for us (GlassFish developers) to ask a user to reenter
a pathname to identify an object (like an app) when we have identified
that object by a shorter unambiguous name to the user as the result of
some prior command on that object.
We (GF developers) gain little, while the user pays for it... every time
they do a redeploy.
vbk
PS; in the one step better... it would be nice to have a mapping of the
object name to the archive file location in domain.xml, so the user
doesn't have to reenter the complete path to an archive to redeploy it,
either...
>
> 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