> 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)
That is a shame. But isn't it so that we should first come up with
a configuration structure (data structure and configuration policy)
for vfs independent of where we get the actual data to this data structure.
Since it takes a lot of data to configure FileSystemManager it is obvious
that we need xml file to hold this data. And the current xml structure is
a good start.
> Now the idea behind this construct was to have a typesafe configuration
> framework.
The configuration container could IMHO be not type safe.
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.
And any missing or erroneous stuff would be reported at that point.
Which to me would be a very natural point for letting the user know
that something is wrong in his configuration file.
The configuration data structure could mention the providers
and their data types making it type safe.
Anyway, now it seems to me overly complex when the issue is quite simple.
In the simplest case we would just need a naming convention and meaning for different
configuration elements.
Example:
Sftp provider accepts the following configuration elements
- 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
...
This same "configuration data structure" class could be used when overriding
in case of resolveFile()
> >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?
- rami
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
