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 11:56:15 GMT
Rami Ojares wrote:

>But isn't it so that we should first come up with
>a configuration structure (data structure and configuration policy)
The data structure for the FileSystemManager is already there: the 
DefaultFileSystemManager already is able to hold the configuration.

There are currently two configuration structures:
1) VFS System (provider, schemes, file-name extensions, mime-types) 
anything which can be configured directly using DefaultFileSystemManager 
or by xml using StandardFileSystemManager
2) FileSystem
If you call Manager.resolveFile for e.g. an http url, a new filesystem 
will be created. But depending on the url one might use different 
filesystem options.
This is where the FileSystemOptions comes in.
It is possible to call Manager.resolveFile with different sets of 
FileSystemOptions and (if not already existent) a new Filesystem will be 
created associated to this options.

So it is not possible to leave the configuration to the HttpFileProvider 
to handle this case, this is merley a thing the filesystem has to deal with.

>>Now the idea behind this construct was to have a typesafe configuration 
>The configuration container could IMHO be not type safe.
But it is now, and it works.

>Because once you call configure() right after instantiation
>the filesystem manager passes provider specific configuration
>to providers and all the providers would configure themselves too.
As i wrote above, the FileSystemOptions configures the filesystem and 
not the provider.
The only thing needet is the abillity to set "default" 
FileSystemOptions, and this can be done after configure() but before the 
first Manager.resolveFile().

>Anyway, now it seems to me overly complex when the issue is quite simple.
I dont see why you mean it is "overly complex" now?
In fact i like it during development to be assisted. And nothing other 
would like the various *ConfigurationBuilder do.
I do not have to read a documentation to see what type a configuration 
parameter should be, the code forces me to do it right. Errors are shown 
during compile time.
And even if you write e.g. a gui to let the user configure some aspects, 
you could use reflection to get the wanted type and assist the user.
Also every possible configuration option is documentend - not only as 
text, but also in code, if you add a new option to the code, the 
documentation is immediatley available in javadoc and you do not have to 
think to add them there - or on any other place - too.

>In the simplest case we would just need a naming convention and meaning for different
>configuration elements.
>Sftp provider accepts the following configuration elements
even if i repeat me, not the provider, the filesystem accepts the 
following configuration ....

>- sftp.known-hosts
>	A path (String) that must point to a valid known-hosts file
>- sftp.private-key
>	A path (String) that must point to a valid private key file in XXX encoding
... and those can change depending on the used sftp url.
However, if we would like to add "options" to the ant thask - for sure, 
then we need a naming convention - and reflection or a wrapper class 
which is able to set the values to the 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.
>Is this really reason enough for the added complexity?
Here i do not understand your comment - using your own derived 
FileSystemManager is another story - what if one would like to write its 
own FileSystemManager to not use the xml at all, but would like to use 
commons-configuration - or any other strategy to read the configuration.


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

View raw message