Hi, Vince
For the v3 technology preview release last year, Jerome has come up
with a set of commands which can be used for the most common use cases,
such as deploy, undeploy. Some of the commands are similar to v2
commands and some of the commands are new. Now we are working on the
official release for v3, one task we have is to maintain backward
compatibility with v2, and this includes providing the same set of the
admin cli commands as in v2. And we need to make choices with the cli
commands that were previously available in v3 preview, but are different
than the existing v2 cli commands.
In general, we don't want to keep two set of commands which do
similar things as it could be confusing to user and also require us to
do more maintenance. So the default is if there are two similar
commands, we keep the v2 command syntax. And in some cases, like the
asadmin redeploy command, as there might still be some value in
providing the new command, we "alias" it to a similar v2 command
("asadmin deploy --force=true") so we only need to maintain one code path.
One thing we need to do but haven't done so (as the command
implementation is still on going) is to provide a mapping of the v3
preview commands and the equivalent commands that are currently
supported in v3. Then we can look at the mapping, and decide what we
like and what we don't like. And for example, if it's by popular demand
to have the redeploy command with the "name" option, and not the "path",
we will try to accommodate that.
Jane: as the implementation of deployment related commands was just
completed, can you provide such mapping so people know what to expect in
v3 technology preview 2 release? And we would still have time to
accommodate any necessary changes before the code freeze.
Thanks,
- Hong
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?
>
> 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...
>
> 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?)
>
> Jane Young wrote:
>
>> Hi Vince,
>>
>> It's not broken... the syntax has changed for redeploy :-)
>>
>> Jane
>>
>>
>> Vince Kraemer wrote:
>>
>>> It seems like a bad idea to break something that has been working...
>>>
>>> Why did this get changed?
>>>
>>> vbk
>>> Jane Young wrote:
>>>
>>>> Hi Ludo,
>>>>
>>>> The correct syntax for redeply is to use the full path.
>>>> "redeploy" is the same as "deploy --force=true <path>".
>>>>
>>>> Jane
>>>>
>>>> Ludovic Champenois wrote:
>>>>
>>>>> so what is the real syntax for redeploy or a dir deployed app?
>>>>>
>>>>> With TP1, this used to work:
>>>>>
>>>>> http://localhost:8080/__asadmin/redeploy?name=WebApplication18
>>>>>
>>>>> Since the name 'WebApplication18' is known and it's location is
>>>>> known (see the list-application), then this command should work
>>>>> for dir deployed app, no?
>>>>> Should I do instead:
>>>>>
>>>>> http://localhost:8080/__asadmin/redeploy?path=FULLPATH
>>>>> ?
>>>>> Ludo
>>>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>