AW: Dynamic loading of FileSystemProvider instances

[Christian Schlichtherle]

> I don't think I fully understand it. If there are providers on the
> class
> path then they should be returned by the
> FileSystemProvider.installedProviders method.

This method uses a ServiceLoader which loads the FileSystemProvider class
names from a resource on the class path and instantiates one instance for
each line entry, right?

Well, that's the problem: The resource is created at compile time, so
whatever I put in there I have no chance to determine the number of
FileSystemProvider instances at run time.

However, I really need a way to do this because the FileSystemProvider class
is limited to exactly one scheme. However, TrueZIP supports an arbitrary
number of schemes and I cannot predetermine them in a reliable way. For
example, at run time I might figure that I need to have a FileSystemProvider
for the following schemes:

"tzp.file" for mapping Path URI "file:/foo.zip" to FsPath URI
"zip:file:/foo.zip!/".

"tzp.file.c" for mapping "file:///C:/foo.tar" to "tar:file:/C:/foo.tar!/"

"tzp.file.d" for mapping "file:///D:/foo.tar.bz2" to
"tar.bz2:file:/D:/foo.tar.bz2!/"

"tzp.http" for mapping "http://download.oracle.com/everyting.zip" to
"zip:http://download.oracle.com/everything.zip!/"

"tzp.https" for mapping "https://download.oracle.com/everyting.zip" to
"zip:https://download.oracle.com/everything.zip!/"

etc etc...

I hope this makes it clear now. This is really an important issue. I need to
have a chance to figure the number of FileSystemProvider instances at run
time, otherwise TrueZIP's FileSystemProvider implementation would be
seriously crippled because I can use only one scheme per FileSystemProvider
instance.

Regards,
Christian