Jane Young wrote:
> vince kraemer wrote:
>
>> You are right. Broken depends on your perspective.
>>
>> So, the question of, "why did this (the syntax) get changed?" remains
>> unanswered.
>>
>> Can anyone answer that question?
>
> The syntax is changed since we don't want to support two different
> code paths since redeploy is essentially the same as "deploy
> --force=true".
This operation is the same from the asadmin programmers perspective... I
think Ludo has already made a strong case that it is not the same from
the asadmin users perspective.
How will this correction benefit users?
>
>>
>> In the case of directory deployed web apps, etc... the user has
>> entered the name and the path to deploy the app, right?
>>
>> The domain.xml has the correct path associated with the name and
>> should just use that, if there is no path argument given.
>>
>> I think the new "correct" syntax is actually asking tools and users
>> to reenter data. (I cannot really tell, since I don't see any
>> definitive reference for redeploy through the web admin
>> interface)That seems like it will make mistakes easier to make... not
>> harder...
>
> How did NB plugin handle this issue in v2?
I do not see why this is a relevant question, but will answer it anyway.
The plugin for V2 uses jsr-88 apis for archive based deployment and the
"DeploymentFacility" for directory based deployment. Both of these APIs
expected the "path" to the object being redeployed. In the case where
an object is directory deployed... this path information is
redundant... since the server already knows the path to the object
being redeployed... it is in domain.xml. The API was weak and Jerome had
made a significant improvement... that we could propagate out to users
as a "redeploy" command that requires less user input (in some cases
significantly less).
That is part of the reason why the redeploy "API" in early releases of
V3 eliminated the path.
> From NB, it should know the path to the application; why does it
> need this information from domain.xml?
It doesn't. It is a program and is less likely to reenter redundant data
incorrectly. If it does, it is my fault.
The issue that I am trying to make clear is a usability issue. The
current implementation of redeploy as "deploy --force=true PATH"
increases the likelihood that a user will enter incorrect data...
because they need to do more typing. And a fair bit of that typing is
to re-enter data that the server already has (in domain.xml).
vbk
>
>>
>>
>> vbk
>>
>> PS: I also noticed that Ludo's original question was not answered
>> directly... "what is the real syntax for redeploy or a dir deployed
>> app?" (which I think is really... what is the real syntax for
>> redeploy of a dir deployed app?)
>
> The syntax is the same as v2. Currently, the supported options for
> deploy command in v3 (for TP2) are:
> "deploy [--name app-name] [--contextroot contextroot]
> [--virtualservers virtualserver] [--force true|false] [--precompilejsp
> true|false] <archive-file | archive-directory>"
>
> and
>
> "redeploy" = "deploy --force=true"
>
>
> HTH,
> Jane
>