You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by David Jencks <da...@yahoo.com> on 2007/03/07 22:29:47 UTC
Problem with svn head, TagLibConfiguration, xerces, and jdk 1.5 (in geronimo)
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
Re: Problem with svn head, TagLibConfiguration, xerces, and jdk
1.5 (in geronimo)
Posted by Jan Bartel <ja...@mortbay.com>.
Hi David,
There were some changes to the TagLibConfiguration class recently. They
might be tickling this xerces/apple issue.
I've put in what I believe is a fix - svn rev 1645. Could you possibly try it out
as I don't have a mac :-)
I've also opened this issue to track it: http://jira.codehaus.org/browse/JETTY-254
cheers
Jan
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
>
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys-and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
Re: Problem with svn head, TagLibConfiguration, xerces, and jdk 1.5 (in geronimo)
Posted by Dain Sundstrom <da...@iq80.com>.
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
>