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?

Thanks

If you are interested have a look at
org.apache.jasper.compiler.JSPCompiler.isOutDated()

Here it checks the generated class file against the
JSP file.

Tomcat/catalina correctly spots the source JSP has
changed (using timestamps), but the compiler ignores the
redeployment request.

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
different reason.
If the source URL is a "file:", it doesn't work.
Sun's file url protocol handler always returns zero
for lastModified().
It only works with Tomcat because they use LDAP
to access directories.

Regards,
Adrian

Awesome work kobenauf, I will pass on the work-around.

Thanks,
JT