Details
Bug
Resolved
Major
Description
This issue was reported by eivindo on the #jetty forum:
<eivindjo> janb: the root cause is in ContextHandler.SContext.getResourceAsStream(String path)
<eivindjo> if the resource is located in a jar-file (war), it then calls java.net.URL.openStream which in turn calls several methods – until java.util.zip.ZipFile.ensureOpen() throws an IllegalStateException
<eivindjo> which in turn is catched in SontextHandler.Scontext above and null is returned.
<eivindjo> (line 1346 in v6.1.15)
<eivindjo> why the zip file is closed is another question, though.. :-/
<eivindjo> it may be related to the fact that the overlaid project is added one time to the context path each time a hot deploy is performed? as the resource loader will try to load from the first file handle, that might have been closed during the restart?
What is happening is that AbstractRunJettyMojo.java line 479 is retrieving the webapp.getBaseResource(), which will have been set on the previous deploy to contain the overlaid webapps, and then appending them
all over again.
Activity
| Field | Original Value | New Value |
|---|---|---|
| Status | Open [ 1 ] | Resolved [ 5 ] |
| Fix Version/s | 6.1.16rc1 [ 15074 ] | |
| Fix Version/s | 7.0.0 [ 14176 ] | |
| Resolution | Fixed [ 1 ] |
| Fix Version/s | 6.1.16rc1 [ 15074 ] | |
| Fix Version/s | 6.1.16 [ 14974 ] |
| Fix Version/s | 7.0.0 [ 14176 ] |
As Jan Bartel points out, the overlaid webapps is appended to the base resource collection and that should be avoided as this might cause stale file handles
. However, I am not completely sure if the IllegalStateExceptions thrown by ZipFile.ensureOpen() is related to this issue, as this exception sometimes also is thrown at the initial run, i.e. before the application is redeployed. I am trying to reproduce this in an isolated environment running a minimal set of webapps – no luck so far.