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
Then list-applications shows
foo and foo_1. So this renaming is happening in this case. 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.
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.
$ 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
>