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
>