The Windows file system is extremely aggressive about holding onto file locks for open files - this makes it effectively impossible to redeploy webapps into Tomcat reliably on a Windows platform.
Developers with slow machines be warned
This will significantly impact the startup time of tomcat. On a reasonably fast machine this will DOUBLE the tomcat startup time. It does allow full webapp hot deploy and undeploy on Windows though.
It does NOT allow hot deploy of components (the logic or dao layers).
If you are developing on Windows, you will want to add the antiResourceLocking and antiJARLocking attributes to your base context file context.xml ($CATALINA_HOME/conf/context.xml), so that it reads as so:
<!-- The contents of this file will be loaded for each web application -->
<Context antiJARLocking="true" antiResourceLocking="true" >
<!-- Default set of monitored resources -->
<WatchedResource>WEB-INF/web.xml</WatchedResource>
<!-- Uncomment this to disable session persistence across Tomcat restarts -->
<!--
<Manager pathname="" />
-->
</Context>
The "antiJARLocking" attribute is possibly unnecessary. These options are documented on the Tomcat site at
http://tomcat.apache.org/tomcat-5.5-doc/config/context.html#Standard%20Implementation.
Note that the way this option works is to make a completely clean copy of the entire webapp into a private "temp" directory whenever it detects a redeploy. This in theory will slow up deployment and chew up disk space, but in practice on modern machines the delay is barely noticeable, even when deploying bulky webapps.
Don't forget to look into $CATALINA_HOME/temp and clean it out from time to time, since the same resource locking issues prevent Tomcat from being able to delete stale versions of your webapps.
You should NOT turn this option on in production.
The antiResourceLocking option can stop JSPs from redeploying when they are edited (a reploy of the webapp is required instad and sometimes a clean out of the work directory).
There are small restrictions apparently on not being able to get certain kinds of resource paths to webapp resources for webapps that are being run from the special "temp" area but we have never run into them in practice.