On 06/03/2015 15:30, Jeremy Boynes wrote: > 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.
Interesting. The deciding factor for me will be performance. Keep in mind that we might not need all the API. As long as there is enough to implement WebResourceSet and WebResource, we probably have all we need. Mark --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
