Last night, I ran a web app of mine on Tomcat 5.5.4. For a long time since then I had been using 5.0 or 4.1.30. So things intergrated pretty with 5.5.4 quickly and was impressed, for a while. Then I encountered the problem that my undeploy ant task didn't work. In fact, I also went to the tomcat manager web app on tomcat and found out I could not undeploy there either.
Well, it seems that when you do an undeploy you will find in your tomcat filesystem, some jar resources still lingering. Somehow keeping resources tucked away makes the system faster and is some sort of weird feature (read that on one of the mailing lists).
Anyways, I stumbled on the solution. In the context.xml file that is in your META-INF folder you must add to the context tag two attributes. Those attribute are antiResourceLocking and antiJARLocking. Once you set these attributes equal to true, things ought to flow better so that you can easily undeploy and deploy from now on. Below is a sample of a context.xml file with these attributes.
<Context path="/myapp" docBase="myapp" debug="0"
reloadable="true" antiJARLocking="true" antiResourceLocking="true"/>
Here is the link to the context.xml reference to help you out with other attributes and elements that you can put into the context.xml file.
Fri, 7 Jan 2005 10:42 PM GMT
then drop tomcat, and go resin :-) http://www.caucho.com/
Wed, 12 Jan 2005 01:23 AM GMT
We've been having the same problem with files being locked. We've tried adding the antiResourceLocking flag to the conf/context.xml file.
Apparently if set, the war files are extracted to the temp directory, but we don't see them.
Does this work for anyone else?
Wed, 12 Jan 2005 06:11 AM GMT
antiResourceLocking should be able to remove any resources when your undeploy using the ant task, or through the manager console. I haven't heard about actually moving them to a temp directory.
Mon, 17 Jan 2005 07:27 AM GMT
Greetings from a parallel universe! A mysterious place where the above trick just does not work.
See issues.apache.org/bugzilla/show_bug.cgi?id=32048
Wed, 28 Mar 2007 09:04 AM GMT
i had the same problem i used those two flags and it worked
Wed, 23 May 2007 03:50 PM GMT
I find that I have to stop the tomcat services, then go into the webapps directory and manually delete the old war and directory that the manager was supposed to undeploy, then deploy the new *.war file. Seems like a lot of manual labor for such a simple task. I haven't tried the fix yet though. Which content.xml file do you stick that in. The current app that your working on, or the content manager in tomcat?
Thu, 21 Feb 2008 07:46 AM GMT
Your suggestion of creating the context.xml with the settings that you have indicated, did indeed work for me. I am using tomcat 5.5.25. Thanks a lot.
Tue, 25 Mar 2008 10:28 PM GMT
Thanks, it did work for me
Fri, 30 May 2008 04:45 AM GMT
You are save my life!!! I love You!!!!!
Sat, 31 May 2008 02:12 AM GMT
Yes, the ant task seems to work after setting antiResourceLocking attribute to true. But the problem is that if you are using this project in the development stage and if you are changing the JSPs, the changes are supposed to be reflected on the page without restarting the server. But I noticed that antiResourceLocking=true setting is causing a problem by which we can't dynamically edit JSPs during the development. When I remove this attribute, I could able to see my changes immediately. This is really annoying.