Unable to perform a remote redeployment of non-ROOT app with version suffix to Tomcat 9.x when an old version exists


Attempting to deploy a webapp named something other than 'ROOT' and including a version suffix such as 'XXX##4794_2020-06-17' to Tomcat9 fails. The identical maven config but with 'ROOT##4794_2020-06-17' deploys properly

Here is the pom.xml. The variable ${warFileName} is set to XXX##<version> via Gitlab runner with the appropriate build and date as the suffix such as "4794_2020-06-17"

The mvn command being used is:



S. Ali Tokmen
June 17, 2020, 10:42 PM

I think I understand the issue: this is caused by the fact that when a deployable has a version the undeploy command will try to undeploy that specific version, in your case obviously the existing version is a different one.

Steve Lopez
June 17, 2020, 11:52 PM

good news - your first suggestion worked! And my apologies for the confusion. In reading the documentation I had misunderstood ‘deploy’ and ‘redeploy’ to be effectively synonymous.

I’m happy to test the SNAPSHOT. However, if i understand what the update does correctly i don’t think that’s what folks would expect. If it tries to undeploy all versions in that context then that means it’ll end up expiring active sessions for older versions of the that same application in that context. Part of my goal with using Cargo is to allow us to deploy minor updates without killing existing user sessions. Let me if I am misunderstanding what the SNAPSHOT does though and I’ll be happy to try it

Thanks again!


S. Ali Tokmen
June 18, 2020, 5:14 AM

Hi Steve

Thanks, I actually changed the implementation a little bit, as I noticed undeploying all versions actually kills versioning Here’s what the latest SNAPSHOTs do when undeploying / redeploying:

  • For Tomcat 6.x and earlier, there is no versioning anyway

  • For Tomcat 7.x onwards, as well as all TomEE versions:

    • In only undeploys a existing application if the path and version match
      This also implies that when redeploying, if there is a different version then that version is not undeployed (ever)

    • If one sets the property cargo.tomcat.undeploy.allVersions to true, then only the undeploy and redeploy commands undeploy all existing versions
      The default value for that property is false

As you seem to be using versioning, I’d be happy to see what you see when you try out the SNAPSHOT version. So, if you can please give a try and let me know.


Steve Lopez
June 18, 2020, 1:33 PM

Sure thing. I just ran a couple of tests using the 1.7.14-SNAPSHOT and I think everything looks good.
Note: for all of these tests i set undeployOldVersions=”false” in server.xml just to make sure testing wasn’t confounded by Tomcat removing wars that didn’t have any sessions.

Test #1: ‘deploy’ with an existing version of the app

Result: Success. Existing version of war file was correctly retained and new version deployed

Test #2: ‘redeploy’ with an existing version of the app

Result: Success. Both prior versions were retained (original version and version from test#1 above) and new version deployed

Let me know if you can think of any other test cases you’d like me to run


S. Ali Tokmen
June 18, 2020, 7:53 PM

Hi Steve

Thank you very much for these detailed tests

I'll then close this JIRA, and it'll be part of our next release.



S. Ali Tokmen


Steve Lopez


Fix versions

Affects versions