tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject DO NOT REPLY [Bug 29286] - Undeploy App does not delete WAR file
Date Thu, 15 Jul 2004 20:11:25 GMT
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=29286>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=29286

Undeploy App does not delete WAR file





------- Additional Comments From bugzilla.e.wuuza@xoxy.net  2004-07-15 20:11 -------
I'm pretty certain what I described in comment 2004-07-14 21:18 is accurate 
because the handle showed up as soon as I stepped into the part where the jar 
is opened to list the files, and the handle is associated with java.exe.
As mentioned, I tried turning off the caching, but I did it within the debugger 
and that could have screwed up the finalization of the objects.  That was 
easier than trying to get the sources set up enough to build a new tomcat.  I 
guess a real attempt to flip caching would be something like changing

    stream = contextXml.openStream();

to

    URLConnection urlConn = contextXml.openConnection();
    urlConn.setUseCaches(false);
    stream = urlConn.openStream();

I'm not sure if I'll get to try that anytime soon.  For now copying the manager 
app from 5.0.19 to the 5.0.25 installation solves the issue and works fine, at 
least for what we're using it for, and I'm busy with other things.  This almost 
seems like it should be called a JDK problem, as I doubt anyone would really 
expect the above code to do such a thing.

Thanks for the input and good luck with the refactoring.

---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org


Mime
View raw message