commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mario Ivankovits <>
Subject Re: [vfs] FileSystemManager construction rethought
Date Wed, 23 Jun 2004 07:47:35 GMT
Hello Rami,

here are some thoughts about "configuration":

*) GlobalConfiguration:
As you have seen, the StandardFileSystemManager currently uses an xml 
file to configure the system.
I tried to replace the parsing of the xml file by commons-digester & 
beanutils but failed as it comes to the point to add those dependencies 
to vfs. Other people vetoed against it (Too large jars)
If i had ever finished this new configuration parsing the result would 
be a object structure useable to pass to the DefaultFileSystemManager.
The GlobalConfiguration is one of the relicts of this try and maybe i 
will remove it and place its current members to the 

*) FileSystemConfigBuilder:
Is the try to configure various aspects of a FileSystem (e.g. for http 
proxy & authentication, for sftp the key location, ...)
So the container for all those options is a instance of 
"FileSystemOptions", but there are no public methods to add 
configuration parameters into it.
Every filesystem which could be configured do have its own 
FileSystemConfigBuild e.g. for sftp this is SftpFileSystemConfigBuilder.

Now the idea behind this construct was to have a typesafe configuration 

FileSystemOptions opts = new FileSystemOptions();
SftpFileSystemConfigBuilder.getInstance().setKnownHosts(opts, new 

On resolveFile it is possible to pass this "opts" in and if it comes to 
the sftp-filesystem it picks its options out of "opts".

Currently this is the only way to pass options into the system, but for 
sure, we need a method on the DefaultFileSystemManager to set the 
"defaults" and allow some kind of "override" of this options at 

IMHO you could finish your work without loose your time with handling of 
FileSystemOptions - this is a complicate part on its own, to make this 
work in ant and from the xml configuration we need reflection.
Drop your FileSystemConfiguration and replace it by a simple string 
which holds the class for the filesystem manager.
I will have a look at GlobalConfiguration (and maybe drop it too) and 
find some way how to pass in a "global/defaults/..." FileSystemOptions 

>One question that arose is that why would someone want to write
>a different FileSystemManager implementation. Could the DefaultFileSystemManager
>be made so configurable that this would not be needed?
One reason could be not to use the xml file for configuration, but write 
a custom FileSystemManager which does the whole configuration in code.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message