IMHO, this is a bug in caching inside
JarURLConnection.
The connection gets into an inconsistent state. The
when you ask for something from the same jar again,
you get back a broken connection.
This might be a better solution :
A workaround is to do something like ask for
jar:file:///a/b/./c.jar!...
instead of
jar:file:///a/b/c.jar!...
The cache fails to find the broken connections and
gives you a fresh one.
This works for me on Linux. I haven't tried it
anywhere else, but I'd like to know if it works OK,
because it is going into the Jetty stuff !
Jules
--- David Jencks <[EMAIL PROTECTED]>
wrote: > On 2001.11.28 06:08:54 -0500 "Jung , Dr.
Christoph"
> wrote:
> > Hello,
> >
> > I just tried to get jboss.net in-sync with the
> latest RH changes and now
> > I
> > am catching a strange
> >
> > java.lang.IllegalStateException: zip file closed
> >
> > when trying to access resources that have been
> placed in my
> > jboss-net.sar!
> >
> > In my mbean, I�m doing a
> >
>
getClass().getClassLoader().getResource(<relative_filename>)
> which
> > returns
> > as expected a non-null URL. But doing an
> > openStream() on that URL will provoque the above
> Exception ... which I
> > guess
> > is due to the fact that the JarFile-Cache
> (shudder) of JarURLConnection
> > is
> > returning
> > an already closed file.
> >
> > But who has closed that file? Why is it that
> classloading works, but
> > resource loading does not?
> >
> > Has there been some change to deployer/system or
> other code that could
> > hint
> > to the reason of above bevaviour?
> >
> > I remember Marc and Rickard discussing things
> related to "closing and
> > reopening of urlconnections" one or two day ago,
> but could not find any
> > related updated to the codebase.
>
> I ran into this problem with the last set of
> deployer changes. I was
> trying to not unpack the xml dds from the copied
> package, and could not
> access them. Therefore I copied them out and used a
> file url.
>
> I don't have a good solution. Two possibilities
> are:
>
> --All the xml files in a sar are already copied to
> plain files. Theres a
> list of them (where they are) in the
> DeployerMBeanSupport.DeploymentInfo
> object. If your resources are xml files perhaps you
> could get the
> DeploymentInfo and find out where the file got
> copied to.
>
> --You could use the "local directory" feature to
> have a directory
> containing your resources copied to a known location
> (currently db). You
> might want to implement the long-discussed filed
> system root mbean to tell
> you where this is.
>
> I don't like either of these solutions. Anyone have
> a better idea or know
> whats wrong?
>
> david jencks
>
>
> >
> > Puzzled,
> > CGJ ("Dr. Schorsch")
> > Currently spinnin� all-time soul classic: Larry
> Heard, "Another night"
> >
> >
> > _______________________________________________
> > Jboss-development mailing list
> > [EMAIL PROTECTED]
> >
>
https://lists.sourceforge.net/lists/listinfo/jboss-development
> >
> >
>
> _______________________________________________
> Jboss-development mailing list
> [EMAIL PROTECTED]
>
https://lists.sourceforge.net/lists/listinfo/jboss-development
__________________________________________________
Do You Yahoo!?
Everything you'll ever need on one web page from News and Sport to Email and Music
Charts
http://uk.my.yahoo.com
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
