Versions Compared


  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Migrated to Confluence 5.3
titleThis is just one way of deploying to Tomcat, not the only one

Similar to the "sister guide" (Developing with Tomcat and Eclipse), there's more than one way to skin the deployment cat. With Maven, good options are the Tomcat plugin and the Cargo plugin. Modern PaaS platforms also typically have their own cluster deployment tools. However, this guide is specifically for Tomcat 7 using its parallel deployment feature. - Kalle Korhonen /


Little convoluted perhaps readable and straightforwarded. The important thing to note is that Tomcat's parallel deployment feature relies on special naming convention of the war file, with double hash (#) character separating the version from the context/war file name. Above, I'm using the BUILD_NUMBER variable as generated by (Jenkins) CI system but you are of course free to use any other version identifier, however Tomcat only understands alphabetical ordering of version identifiers. Another thing to note is that currently the previous versions are not unloaded automatically, they are by default but just passivated. This causes the memory to fairly quickly run out which is why I'm simply manually deleting the previous war files that causes Tomcat to undeploy and remove their exploded webapp folders. For continuous delivery, you most likely want to set Host attribute undeployOldVersions for removing previous instances, i.e. have something like this in your Tomcat's server.xml configuration file:

Code Block
<Host name="localhost"  appBase="webapps" unpackWARs="true" autoDeploy="true" undeployOldVersions="true">

Finally one more note about the parallel deployment is that if loading the new version of a webapp fails, it'll never become active, so you always have a version of the webapp in a runnable state.