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
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.
Add autoDeploy = true. Works for me
<Host name="localhost" appBase="webapps" unpackWARs="true" autoDeploy="true">
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.
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.
In my case i name artifact
ROOT.WAR
but should be
ROOT.war
Cheers!
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.