31
votes

I followed the following steps

  • Shutdown Tomcat
  • Deployed a war file with a timestamp of 1st December
  • Start Tomcat - This created the exploded directory for the deployed war file.
  • Stop Tomcat
  • Updated the war file with a new one with a timestamp of 3rd December
  • Restart Tomcat

I found that when i restarted Tomcat, the existing files in the folder that was expanded previously were not updated. Shouldnt the update to the war file have updated the relevant jsp, class file?

I looked at the documentation and found this http://tomcat.apache.org/tomcat-5.5-doc/config/host.html. The following quote under "Automatic Application Deployment"

In addition to the automatic deployment that occurs at startup time, you can also request that new XML configuration files, WAR files, or subdirectories that are dropped in to the appBase (or
$CATALINA_HOME/conf/[engine_name]/[host_name] in the case of an XML configuration file) directory while Tomcat is running will be automatically deployed, according to the rules described above. The auto deployer will also track web applications for the following changes:

  • An update to the WEB-INF/web.xml file will trigger a reload of the web application
  • An update to a WAR which has been expanded will trigger an undeploy (with a removal of the expanded webapp), followed by a deployment
  • An update to a XML configuration file will trigger an undeploy (without the removal of any expanded directory), followed by a deployment of the associated web application

Shouldnt the files have been automatically been updated as a result of point 2 above?

Autodeploy is set to true in server.xml

6

6 Answers

33
votes

Historically, tomcat has never updated the exploded directory when you just drop in a new jar, at least for me. I always assumed this to be a bug, but never looked into it as there is a simple solution. Both of these should work fine:

  • Deploy the war file using the build-in Manager application. Fine if you are ok with using a GUI for production administration. Note This tool used to have issues if you deployed multiple times (again, I never delved into the details), but a Tomcat restart worked fine.
  • Stop, Delete, and Drop. Stop Tomcat, delete the exploded directory, drop in the new war file.
  • 8
    votes

    Add autoDeploy = true. Works for me

    <Host name="localhost"  appBase="webapps" unpackWARs="true" autoDeploy="true">
    
    7
    votes

    I usually set the autodeploy in server.xml to false. This allows me to drop the new war and restart tomcat without having to deal with the corresponding directory.

    2
    votes

    Yes the exploded directory ought to be updated, however you don't need to stop Tomcat for this to work - it will work with Tomcat running. Can you try it again without stopping Tomcat in between the update?

    Also I use the built-in Manager application which allows me to update war files anywhere in the domain without being root (or apache or whatever tomcat is running as). This is very convenient and can be built into an Ant script.

    2
    votes

    As I use maven to generate my builds in tomcat inside a ubuntu box, I have a script called

    install_wars.sh

    With the following content:

    mvn clean install
    service tomcat7 stop
    find /var/lib/tomcat7/webapps/ -mindepth 1 -maxdepth 1 -type d -exec rm -rf {} \;
    find . -name *.war -exec cp {} /var/lib/tomcat7/webapps/ \;
    service tomcat7 start
    

    You may want to change the path and maven commands accordingly.

    The tomcat stop/start are there to avoid any memory leaks that can make the application slow after several redeploys.

    1
    votes

    In my case i name artifact

    ROOT.WAR
    

    but should be

    ROOT.war
    

    Cheers!