commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rami Ojares" <rami.oja...@elisa.fi>
Subject Re: [vfs] FileSystemManager construction rethought
Date Thu, 24 Jun 2004 10:28:35 GMT
Hi Mario,

Here I have listed my current understanding of VFS in connection with
the configuration issues. Could you please correct any mistakes you find.

- Manager contains FileProviders
- Manager supports all schemas for which it has configured a provider
- FileProviders create a FileSystem the first time a file is resolved against
them
- FileProviders create a new FileSystem everytime a new FileSystemOptions is
encountered
- FileSystem is in a way "active" meaning that it contains a live connection over
some protocol if that is needed to access the files on the filesystem.
- User can create layered filesystems on top of originating filesystems
- User can create virtual filesystems and add junctions to them

So if these points are correct the configuration data stucture contains the
following:
- Manager specific configuration independent of providers
Q: What are these?
- Provider specific default configuration (manager instantiates and configures the
providers it supports)
- ad hoc configuration when resolveFile is called

And then my understanding of the current configuration mechanism

- StandardFileSystemManager configures the manager and providers from xml
- resolveFile method provides FileSystemOptions that results in creation of
FileSystem if the options were never given before.
- every invocation of resolveFile can potentially result in creation of a
FileSystem
- FileSystemConfigBuilders provide type safety to FileSystemOptions
- FileProvider must provide a FileSystemConfigBuilder that is used to create
FileSystemOptions suitable for that provider's filesystems

==> FileSystemOptions are the only configuration data structure in place at the
moment and it is the duty of FileSystemManager and FileProvider implementations
to provide for their own configuration.

Let's consider configuration of a logger to FileSystemManager.
setLogger() is a method in DefaultFileSystemManager.
Further it utilizes setLogger method in VfsComponent interface that is
implemented by FileProviders and FileSystems (among others).

So from the point of view of ant task that wants to set a logger
to the manager it uses, there should be setLogger() in FileSystemManager
interface. Because if it can choose manager implementation then it would
have to use introspection to find setLogger() and it would have no guarentee
that such method exists in the implementation.

This might not be seen as problem. But let's take it further.

Consider ant fragment

<vfs-manager refid="mymanager" class="MyManager" configuration="path/to/conf"/>
    
<vfs-copy todir="sftp://host/usr/local/var">
    <vfs-manager ref="mymanager"/>
</vfs-copy>

In the configuration file there would already be pointers to knownHosts and
privateKey files so one would not have to tell them inside the uri.
But if one would tell them for example
sftp://id=/path/to/.private.key;knownHosts=some/path@host/usr/local/var
then that would just override the providers defaults set from the configuration
file.

Now the configuration (file) can be passed as path, File, FileObject, DOM or
whatever. But it would be nice if FileSystemManager interface would dictate at
least some kind of configuration framework so the ant tasks would not have to
mention any implementations.

- Rami Ojares

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message