Hi Hong,
The --contextroot provides kind of namespace to the deployed
application. The application name is computed from the war file name by
default. Could --contextroot value not provide --name option value in
this case and so resolve the name conflict. I am assuming --contextroot
is a unique value on the running instance.
-vivek.
Hong Zhang wrote:
> Hi, Vivek
>
>> There is also --contextroot option of deploy command that affects
>> application deployment differently.
>>
>> Currently I can do
>>
>> deploy --contextroot /foo foo.war
>> deploy --contextroot /foo1 foo.war
>>
> This is the part I plan to change (see the second part of my previous
> message). The code currently tries to resolve name conflict and assign
> a new name automatically in this case.
> With the change I am about to make, it will fail and ask you either to
> use force option if it's a redeployment or specify a different name if
> it's new deployment.
>
>> Then list-applications shows
>>
>> foo and foo_1. So this renaming is happening in this case.
>
> Yes, the automatically resolving name conflict is happening in this
> case in the current code.
>
>> The only way you would undeploy the deployment at /foo1 will be by
>> after running list-applications and finding which name is assigned to
>> it. I think this is confusing, maybe deploy command should print the
>> application name as part of success message.
>
> Yes, I plan to add a message for this also.
>
>> However when trying to deploy with --force to either of the context
>> root above will fail the deployment, is this is a bug or expected
>> behavior? I would think its former.
>
> Yes, it's expected. We interpret the force option as redeployment, so
> we don't try to resolve name conflict there.
>
> With my new change, we will not try to resolve name conflict and
> reassign new name, it will be a lot clearer.
>
> - Hong
>
>>
>> $ asadmin deploy --force=true --contextroot /foo1 foo.war
>> com.sun.enterprise.admin.cli.CommandException: remote failure:
>> Exception while loading the app : java.lang.Exception:
>> java.lang.Exception: WEB0113: Virtual server [server] already has a
>> web module [foo_1] loaded at [/foo1]; therefore web module [foo]
>> cannot be loaded at this context path on this virtual server.
>>
>> -vivek.
>>
>>
>> Hong Zhang wrote:
>>
>>> Hi, Bill
>>>
>>>> A few of us have been discussing some issues with deployment
>>>> recently and
>>>> I'd like to let everyone know what we ended up with and get your
>>>> feedback.
>>>>
>>>> We have three ways to deploy an application using the command line and
>>>> two cases to consider for each operation.
>>>>
>>>> Here's what we came up with:
>>>>
>>>> | foo does not exist | foo exists
>>>> ------------------------------------------------------------
>>>> deploy foo.war | + | X
>>>> deploy --force foo.war | + | + [2]
>>>> redeploy foo.war | + [1] | +
>>>>
>>> Today's behavior for "redeploy foo.war" is we would fail
>>> redeployment when "foo does not exist". If we are not going to make
>>> any of the changes for [1], this row should remain like this?
>>>
>>> redeploy foo.war | X | +
>>>
>>> Also today's behavior for "deploy foo.war" when "foo exists" is we
>>> would resolve the name conflict and assign a new name, so we have
>>> decided we would fail that case? I agree failing would be more user
>>> friendly, I implemented the resolving name part only because I
>>> thought that was the spec requirement. If by having the --name
>>> option already satisfies the spec requirement, I will be happy to
>>> make this change. :-)
>>>
>>> Thanks,
>>>
>>> - Hong
>>>
>>>>
>>>> Possible outcomes:
>>>>
>>>> X - command fails
>>>> + - command succeeds, app "foo" is deployed
>>>>
>>>> There were two changes we considered:
>>>>
>>>> 1. Should redeploying an app that isn't deployed be an error? Is
>>>> it likely
>>>> that you made a mistake if you try to redeploy something that isn't
>>>> deployed to begin with? If you don't care whether or not it's
>>>> already
>>>> deployed why not use deploy --force?
>>>>
>>>> 2. Should deploy --force with an app that's already deployed cause the
>>>> app to be deployed under a different name? The Java EE spec allows
>>>> (but does not require) the deployment tool to choose a different
>>>> name
>>>> for the app if the name conflicts with an already deployed
>>>> application.
>>>> Does --force really mean "replace this app if it's already
>>>> there", or
>>>> does it mean "deploy this new app no matter what, without
>>>> disturbing
>>>> other apps that might be deployed"?
>>>>
>>>> Either of these changes would cause redeploy and deploy --force to
>>>> behave
>>>> differently. We were worried about the compatibility impact of
>>>> such a change,
>>>> both with v2 (for which deploy is already incompatible because
>>>> --force is
>>>> the default in v2), and with v3 where people have come to expect
>>>> these two
>>>> commands to behave the same.
>>>>
>>>> If anyone feels strongly that we should make either of these changes,
>>>> let me know.
>>>>
>>>> Thanks.
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> 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
>>>
>>
>> ---------------------------------------------------------------------
>> 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
>