ASF Bugzilla – Full Text Bug Listing
|Summary:||Cannot undeploy and deploy war file with on the same context|
|Product:||Tomcat 5||Reporter:||Dave Oxley <dave>|
|Component:||Webapps:Manager||Assignee:||Tomcat Developers Mailing List <dev>|
Description Dave Oxley 2004-10-12 21:13:51 UTC
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.
Comment 1 Remy Maucherat 2004-10-12 21:31:38 UTC
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).
Comment 2 Dave Oxley 2004-10-12 21:49:14 UTC
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.
Comment 3 Remy Maucherat 2004-10-12 22:02:24 UTC
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.
Comment 4 Dave Oxley 2004-10-19 21:34:37 UTC
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.
Comment 5 Yoav Shapira 2004-10-25 19:11:15 UTC
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.
Comment 6 Dave Oxley 2004-10-26 14:58:12 UTC
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.
Comment 7 Yoav Shapira 2004-10-26 15:02:55 UTC
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.
Comment 8 Yoav Shapira 2004-10-26 15:03:36 UTC
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.
Comment 9 Remy Maucherat 2004-10-26 15:06:34 UTC
I've added a warning message for the tempdir thing, and that's all that will be done.
Comment 10 Dave Oxley 2004-10-26 16:09:51 UTC
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.