Bug 31677 - Cannot undeploy and deploy war file with on the same context
Summary: Cannot undeploy and deploy war file with on the same context
Status: RESOLVED FIXED
Alias: None
Product: Tomcat 5
Classification: Unclassified
Component: Webapps:Manager (show other bugs)
Version: 5.5.3
Hardware: PC Windows XP
: P5 minor (vote)
Target Milestone: ---
Assignee: Tomcat Developers Mailing List
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2004-10-12 21:13 UTC by Dave Oxley
Modified: 2004-11-16 19:05 UTC (History)
0 users



Attachments

Note You need to log in before you can comment on or make changes to this bug.
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.