Hi, Vivek
> 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.
>
We also have an application name space which requires all application
names are unique, this name space is orthogonal to the context root name
space.
- Hong
>
> 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
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>