When we've had problems like this before, we passed the offending
library with an unclosable stream.
-dain
On Mar 7, 2007, at 1:29 PM, David Jencks wrote:
I'm trying to run svn head inside the geronimo integration and ran
into a bizarre problem (yet again, see below) in which xerces is
closing a JarUrlStream which closes the entire ZipFile thus
preventing any further access to the jar file. Going back to 6.1.0
fixes the problem.
The relevant part of the stacktraces I get look like:
java.lang.IllegalStateException: zip file closed
at java.util.zip.ZipFile.ensureOpen(ZipFile.java:518)
at java.util.zip.ZipFile.getInputStream(ZipFile.java:300)
at java.util.zip.ZipFile.getInputStream(ZipFile.java:286)
at java.util.jar.JarFile.getInputStream(JarFile.java:387)
at sun.net.www.protocol.jar.JarURLConnection.getInputStream
(JarURLConnection.java:136)
at org.mortbay.resource.URLResource.getInputStream
(URLResource.java:206)
at org.mortbay.resource.JarResource.getInputStream
(JarResource.java:106)
at
org.mortbay.jetty.webapp.TagLibConfiguration.configureWebApp
(TagLibConfiguration.java:189)
at org.mortbay.jetty.webapp.WebAppContext.startContext
(WebAppContext.java:1171)
at org.mortbay.jetty.handler.ContextHandler.doStart
(ContextHandler.java:501)
at org.mortbay.jetty.webapp.WebAppContext.doStart
(WebAppContext.java:444)
Putting a breakpoing on ZipFile.close() I found that xerxes (I
think the one in the apple 1.5.0_07 vm) is calling the close method
when it's just trying to close an input stream from a jar entry.
I ran across this problem a couple years ago and solved it with an
UnclosableInputStream that ignored close calls, but I don't quite
see how to apply such a solution here. Before I spend more time
looking I wonder if anyone else has seen anything like this and
might have advice on a solution.
thanks
david jencks
