Have tested whether Bug 29526 is fixed for 5.5.3, but an undeploy still leaves mail.jar in the lib directory. Everything else is deleted. antijARLocking was set to true in conf/context.xml.
antiJARLocking (be careful about case) is not completely foolproof. Use antiResourceLocking if you want true hotdeploy, but it's a lot more expensive in terms of webapp startup time. Please verify if mail.jar is actually locked (= try to delete it manually).
The jar could not be deleted. I did have the case correct (antiJARLocking). I also tried antiResourceLocking but got very strange results. mail.jar was still locked and when I stopped Tomcat the manager and admin webapps got deleted!!! This might be correct as I manually added the contexts for admin and manager into server.xml which I know I'm not supposed to do now.
I did test it, and I think you are not being very constructive in your comments. Tested with Struts' example webapp, precompiled, deployed and undeployed using the Tomcat deployer (which uses the Ant tasks), with both antiJARLocking and antiResourceLocking (which both do deployment where expected). Without one of these two options, some JARs remain, which is to be expected. Please don't reopen this report.
Sorry Remy, this was my fault. I didn't have a temp directory in my base directory. But not having the temp dir really broke things though, so I have reopened the bug with a suggestion that a message is logged and/or the temp dir is created if it doesn't exist.
Tomcat ships with the work dir created. The code already tries to create it if not already created. I've added a warning to be logged if the work dir for a context cannot be determined or accessed.
Sorry I was talking about the temp directory (java.io.tmpdir I think). Could the same be done for the temp directory which is separate from the work directory but is required for the antiJARLocking and antiResourceLocking flags. It would be good if they both worked the same way. Cheers.
No. Java.io.tmpdir is up to server administration control, not Tomcat's. It's assumed to be configured properly and cannot typically be created due to permissions on the server.
Further, if you want to try and come up with a patch that does it, please do so and post it to the tomcat-dev mailing list please so that we can discuss the issue, rather than reopening this Bugzilla issue a third time. It has to work under a SecurityManager as well.
I've added a warning message for the tempdir thing, and that's all that will be done.
I wasn't too sure about creating of the temp dir, I thought it might not be possible or a good idea. I think a warning message is fine. Cheers.