I'm still new, but maybe this will help you... Tomcat/Catalina will extract the war file as soon as it starts or the war is deployed. From there on out, it locks the files that it is using and you can't regain access to those again until you tell Tomcat to do something else. If you look on the Jakarta pages under Tomcat, you'll find some useful manager commands (http://localhost:8080/manager/redeploy?path=/cheesy-war-that-wont-die might be the one you are looking for.) I'm very lazy and I am running my own private developemental server, so I just kill the server rm -rf (rd /q /s for windows) the directory in my script to build and deploy. After it is done, it will restart the Tomcat server. (I run mine independantly.)
A more elegant and correct way can be found here: http://jakarta.apache.org/tomcat/tomcat-4.0-doc/manager-howto.html
This may solve your problem. But the issue will be getting the Tomcat manager working with the integrated JBoss/Tomcat 4.01.
Someone I know is having this same problem on an older machine running Linux.
Has anyone been able to get the Tomcat Manager working with this INTEGRATED JBoss/Tomcat version and if so how?
I think I solved the problem. When you drop a war into /deploy, JBoss unpacks it into /tmp/deploy/Default/. This is important: the files in that folder have the datetimestamp that they had on the machine where you created the war file.
JBoss then compiles the jsp file into a java and class file in /work/localhost/. This newly compiled file has the datetimestamp of the server.
Apparently, JBoss compares the datetimestamp of the existing compiled files to the datetimestamp of the new files in /tmp/deploy/Default/. If the new files have a newer datetimestamp, it recompiles; otherwise it doesn't.
In my case, the clock on my workstation was a few minutes slower than my server's clock. Therefore, if I quickly made changes and deployed again, the datetimestamp of the compiled file from the previous deploy was still newer than the datetimestamp of the new files. Result: the compiled files were not getting updated, and my changes were not appearing in the browser.
I worked around this by setting the time on my workstation a couple minutes ahead of my server.
This looks like a design flaw to me. Comparing datetimestamps is not a good way to see if a file has changed. The JBoss loader/compiler should compare a hash of the file's contents instead, or something similar.
If you are interested have a look at
Here it checks the generated class file against the
Tomcat/catalina correctly spots the source JSP has
changed (using timestamps), but the compiler ignores the
In fact, potentially it is checking the timestamp on
a remote machine against one on the local machine, the
source can be specified by any URL.
I've got an open bug about this with apache for a
If the source URL is a "file:", it doesn't work.
Sun's file url protocol handler always returns zero
It only works with Tomcat because they use LDAP
to access directories.
Awesome work kobenauf, I will pass on the work-around.