Nested ZipFileSystems cause issues with URI parsing

[Alan Bateman]

On 06/06/2020 09:17, Mitchell Skaggs wrote:
> Hi everyone,
>
> I ran into a bit of a complex/niche issue, and I'm not surprised it 
> wasn't caught or brought up before. I have a situation brought on by 
> Spring's Uber-jars where a classpath resource is located inside of two 
> jar files. The standard getResourceAsStream, etc. works just fine 
> because of a clever implementation of URLStreamHandler that does some 
> zipfile magic to find the file offsets inside nested zips. 
> Unfortunately, I need something more powerful than an InputStream - I 
> need java.nio.Paths - so I instead use getResource and recursively 
> consume that URI, opening/closing FileSystems as needed. I expected 
> that to work fine, but due to the way the URI is processed by 
> ZipFileSystem, it looks in the wrong place.
>
> The cause of (and fix for) the issue:
>
> After tracing through the code, here's what I believe to be the crux 
> of the issue: the ZipFileSystemProvider.getPath(URI)method. That 
> method uses String.indexOf on the string representation of the URI. 
> Because of the structure of jar-scheme URIs (link 
> <https://www.iana.org/assignments/uri-schemes/prov/jar>), it should 
> instead use String.lastIndexOf because the first "jar:" scheme is 
> always paired with the last "!/" separator. I believe this is a bug, 
> and fixing it wouldn't change behavior in situations without nested 
> jar files.
The file system API doesn't define a format for so-called compound URIs. 
You'll find more on this in the Path::toUri javadoc where expectations 
that are set that invoking toUri() on a path to a file in a nested file 
system may not return a URI that encodes the URI of the enclosing file 
system. That said, the URI support for nesting of zip/JAR file systems 
does work for one level of nesting and if helps the more general case of 
N-levels of nesting then we should fix it. In addition to the 
getPath(URI) implementation, there may be other other in the zipfs 
provider that will need attention too. A good set of tests should help 
shake out any other issues.

-Alan.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/nio-dev/attachments/20200606/8f2877a7/attachment.htm>