Question regarding extensibility

[Marcel Ammerlaan]

Alan Bateman wrote:
>> I'm trying out the new java.nio.file.* as an alternative to Apache VFS.
>> One striking omission however is the ability to add new filesystems 
>> dynamically:
> The FileSystems class defines several methods to create file systems 
> at runtime. The newFileSystem methods that specify a class loader can 
> be used to locate providers that aren't installed but are loaded via 
> custom class loaders. Furthermore, if you have a reference to a 
> FileSystemProvider then you can just invoke its newFileSystem method 
> directly to create the file system -- ie: it doesn't have to be 
> created via FileSystems. That may help you but I think you are 
> actually looking to register providers at runtime. It would be useful 
> if you could elaborate on how you might use this. At this time we 
> don't keep a global registry of providers. The installedProviders 
> method just returns the list of "installed" provider and would require 
> something else (in FileSystems) to support a global registry.
The use case I'm working on is a container-like environment that hosts a 
plugins (it's comparable to OSGi). The only stable entrypoint in the JDK 
that the plugins can expect is the core java.nio.file.* classes: they 
dont know which filesystems have been loaded. So the most likely way to 
get a Path object is to use the Paths utility class to convert a URI to 
a Path. In this case the custom Filesystem will not be found. The 
workaround here would be to provide an alternative Paths-like 
implementation that does
keep a dynamic registry.

The downside to this is that the plugin starts depending on this 
container-like environment and cannot be reused independant of the 
container (ie. standalone) without additional work.

The other use-case is to provide an alternative provider. The provider 
I'm currently working on is an HTTP provider. A basic one might be 
readonly (ie. based on java.net.URL functionality) whereas a more 
advanced provider might be loaded dynamically (quite possibly via the 
naive HTTP filesystem) adds write-support (something like WebDav for 
example). This provider can actually replace the old provider completely 
for newly constructed Paths.

Hopefully this gives some insight in how I will use the java.nio.file.* 
stuff. The most likely workaround will indeed be a custom registry that 
should be used by the plugins.

Regards,

Marcel Ammerlaan.