When I stop or remove a struts application there is a lock on struts.jar and the applications directory under webapps cannot be removed. Cross posted under struts. To reproduce: Get file 'struts-blank.war' from the struts 1.0 or 1.1Beta binary distribution. Put above file in webapps directory. Start Tomcat In browser type: 'http://localhost:8080/manager/stop?path=/struts-blank Answer password prompt - see tomcat-users.xml in conf directory Verify an 'OK' response. Delete 'struts-blank' directory from webapps directory. Delete fails because struts.jar is locked.
I can't reproduce this problem with Tomcat 4.1.18. Please let me know if you are still having problems with this. If you are, could you please test with Tomcat 4.1.18 to see if it still exists.
Tomcat: 4.1.18/4.1.19 JDK: 1.4.1 System: W2K SP3 I can reproduce this bug on 4.1.18 and 4.1.19 (also with other applications using struts.jar), but it seems rather related to Struts itself since removal of any other webapps works fine for me.
I will mark this bug as invalid for Tomcat then. Please work with the struts team to resolve it. Thanks for checking.
Sorry, apparently I got to reopen this, please read Craig's comments on #10027: http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10027 Seems this problem is related to Tomcat locking (at least some) JARs on WIN
This also occurs with axis.jar. Very frustrating!
A similar bug was fixed in Log4J. While it's arguable whether it's a struts bug, tomcat bug, or a windows bug, I thought I'd post the details to see if anyone has ideas on how tomcat can fix this. The bug (from what I understand) is that when dtd's are loaded from the jar (while running on windows), the jar is locked b/c the input stream for the dtd has not be properly closed. In log4j, this is fixed by using a custom EntityResolver to load the dtd. (the resolver makes a copy of the dtd input stream in memory and return the copied stream after closing the real input stream) references to this can be found in the log4j code, but this url from the barracuda project has a pretty good summary: http://barracuda.enhydra.org/software/cvs/cvsweb.cgi/Projects/EnhydraOrg/toolsT ech/Barracuda/WEB-INF/lib/log4j-1.2.7a.jar?rev=1.1&content-type=text/x-cvsweb- markup the files of interest in log4j are: org/apache/log4j/xml/Log4jEntityResolver.java org/apache/log4j/xml/DOMConfigurator.java is there some way for tomcat to always use a custom EntityResolver if the system is windows? Something that may also be of interest: I've found that if I expand the jar and dump all the files into WEB- INF/classes, there are problems undeploy/removing the app
sorry, typo. that should read: I've found that if I expand the jar and dump all the files into WEB-INF/classes, there are NO problems undeploy/removing the app
I have specifically investigated this problem during the past few days, and can draw the same conclusions. There's unfortunately little or nothing that Tomcat can do. Here's what happens: - XML paser uses get resource to load the DTD - Tomcat returns a jar:file: URL, as the DTD is inside a JAR - XML parser does read from that without setting setUseCaches(false), so this causes the JAR to be locked until the VM is terminated Tomcat cannot do anything about it, unless we add custom code in getResource to handle non class resources (ex: we could extract the resource to teh work dir, and return a file URL to there). AFAIK, there's nothing which forbids that, so I'll experiment with doing that in TC 5.
*** Bug 8763 has been marked as a duplicate of this bug. ***
WORKSFORME for struts.jar in TC5.0.4 on WinXP (both stop and undeploy)
*** Bug 15484 has been marked as a duplicate of this bug. ***
I have ported the antiJARLocking functionality from TC5 and successfully tested it with antiJARLocking="true" using a struts app (a copy of the Tomcat Admin app). The fix will be included in 4.1.32 onwards. Note there is no date currently planned for a 4.1.32 release.