On Mar 4, 2015, at 9:09 AM, Jeremy Boynes <jboy...@apache.org> wrote: > > My suggestion for using an NIO2 FileSystem is because its API provides for > nesting and for random access to the entries in the filesystem. Something > like: > > Path war = FileSystems.getDefault().getPath(“real/path/of/application.war”); > FileSystem warFS = FileSystems.newFileSystem(“war:” + war.toURI()); > Path nestedJar = warFS.getPath(“/WEB-INF/lib/some.jar”); > FileSystem jarFS = FileSystems.newFileSystem(“jar:” + nestedJar.toURI()); > Path resource = jarFS.getPath(“some/resource.txt”); > return Files.newInputStream(resource); // or newFileChannel(resource) etc. > > There are two requirements on the archive FileSystem implementation for this > to work: > * Support for nesting in the URI > * Functioning implementation of newByteChannel or newFileChannel > > Unfortunately the jar: provider that comes with the JRE won’t do that. It has > ye olde jar: URL nesting issues and requires the archive Path be provided by > the default FileSystem. Its newByteChannel() returns a SeekableByteChannel > that is not seekable (doh!) and newFileChannel() works by extracting the > entry to a temp file. > > The former problem seems easy to work around. To support a seekable channel > without extraction would be trickier as you would need to convert channel > positions to the actual position in the compressed data which would mean > digging into the compression block structure. However, I think the naive > approach of scanning the entry data and then caching the block offsets would > still be quicker than inflating to a temp file.
I started exploring this in http://svn.apache.org/r1664650 This has a (very) crude implementation of a FileSystem that allows nesting on top of JAR-style archives using the newByteChannel() API. It enables you to “mount” an archive and than access resources in it using the standard Files API. Still to investigate is how Paths can represented as URIs that can be converted to URLs to be returned from e.g. getResource(). I’m exploring URL-encoding the authority component to allow the base Path’s URI to be stored in a regular hierarchical URI with the nesting simply triggering multiple levels of encoding. This is different to the jar scheme’s approach of using non-hierarchical URIs with custom paths and the “!/“ separator. Hopefully we would be able to create a URLClassLoader from those URLs and have it operate normally. The URLStreamHandler would handle archive: URLs by locating a mounted filesystem and opening a stream to the Path within. We would still need to install a custom URLStreamHandlerFactory. Cheers Jeremy
signature.asc
Description: Message signed with OpenPGP using GPGMail
