AW: Issue implementing FileSystemProvider.getScheme()

[Christian Schlichtherle]

Hi Alan,

> > The problem is that FileSystemProvider.getScheme() can only return a
> single
> > scheme. However, TrueZIP supports plenty of schemes which are
> discovered at
> > runtime. So I cannot add a FileSystemProvider implementation class
> name for
> > each scheme in META-INF/services/java.nio.file.spi.FileSystemProvider
> at
> > compile time.


> The intended way to deploy a virtual file system provider is to choose
> one URI scheme, say "vfs", and have it be the factory for a single
> virtual file system instance. So for what you are doing then possible
> URIs might be be vfs:///, vfs://dir/, vfs:///dir/foo.jar/,
> vfs:///dir/foo.jar/bar.rar/, vfs:///dir/foo.jar/bar.rar/entry, etc.
> Your
> virtual file system provider can delegate to other installed (or
> dynamically located) providers that use other URI schemes but they just
> aren't exposed to the users of the API.

I thought about this already and it seems to be a viable option which should
solve the problem I discussed in my next email, namely registering a custom
application file format.

So I will eventually select "truezip" or "tzp" as the scheme. My TPath
implementation could then get created from the examples you've given above.
Internally, it will map the given URI to a URI for an FsPath object (a class
in the module TrueZIP Kernel). For example, the TPath URI

truezip:/archive.zip/entry

would map to the FsPath URI

zip:file:/archive.zip!/entry

> Going further, if you can eventually eliminate the virtual file system
> provider's dependency on the java.io classes mentioned in the other
> thread, then you can experiment with moving to the "file" scheme and
> making your provider the default provider.  That would make for a nice
> demonstration of everything working together.

I have accounted for this in the architecture of TrueZIP 7. All file system
access is done via the module "TrueZIP Driver File". I have already written
a second module "TrueZIP Driver File JSE7" which uses the NIO.2 API instead.
When using Maven, it will figure your JSE version and select the best
module. When both modules are present on the runtime class path, the drivers
will sort it out themselves. The code is tested and stable. 

Now the missing link is just the TrueZIP FileSystemProvider implementation.
I can't wait to see it done. :-)

Regards,
Christian