32

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

Andreas Dolk
  • 113,398
  • 19
  • 180
  • 268
ziggy
  • 15,677
  • 67
  • 194
  • 287

6 Answers6

33

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.
    • DwB
    • 37,124
    • 11
    • 56
    • 82
    • +1 Same here. I adopted second solution, just make a script to do it. – leonbloy Jan 05 '11 at 13:42
    • I use the second approach but without deleting the exploded directory. Thats the bit that not working :0 – ziggy Jan 05 '11 at 13:57
    • 8
      Tomcat explains this with this paragraph: "Any web application archive file within the application base (appBase) directory that does not have a corresponding directory of the same name (without the ".war" extension) will be automatically expanded, unless the unpackWARs property is set to false. If you redeploy an updated WAR file, be sure to delete the expanded directory when restarting Tomcat, so that the updated WAR file will be re-expanded (note that the auto deployer, if enabled, will automatically expand the updated WAR file once the previously expanded directory is removed). " – David García González Oct 25 '12 at 10:17
    • The thing is, that when you are in production, it's not easy to restart the application server, especially if other applications run under that server instance – stelios May 05 '16 at 10:55
    • Hi, can anyone tell me what `Drop` is here? – tash Sep 23 '21 at 14:52
    • "Drop" means copy the file into the directory. – DwB Sep 23 '21 at 19:24
    8

    Add autoDeploy = true. Works for me

    <Host name="localhost"  appBase="webapps" unpackWARs="true" autoDeploy="true">
    Mircea Stanciu
    • 3,675
    • 3
    • 34
    • 37
    7

    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.

    Ricardo Marimon
    • 10,339
    • 9
    • 52
    • 59
    2

    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.

    Panthro
    • 3,247
    • 2
    • 32
    • 37
    2

    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.

    trojanfoe
    • 120,358
    • 21
    • 212
    • 242
    • 2
      We dont have the manager or admin apps installed on the production environments so it is all done via a script. I agree that the exploded folder should be updated. I wonder if whether the fact that i shutdown tomcat causes this. – ziggy Jan 05 '11 at 13:28
    1

    In my case i name artifact 

    ROOT.WAR

    but should be

    ROOT.war

    Cheers!

    Andrew
    • 122
    • 7