Hong Zhang wrote:
> 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.
>
Yes, but point is that they are related - together they are unique
values. The point was that they are kind of one and the same in certain
cases. By default contextroot is derived from application name and in
the case of name conflict if --contextroot is provided and is unique,
why not use it for name resolution rather than asking user to provide
--name value.
-vivek.
> - 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
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>