Hi Ralph,
Ralph Goers wrote at Mittwoch, 19. August 2009 00:54:
>
> On Aug 18, 2009, at 12:48 PM, Jörg Schaible wrote:
>
>> Hi Mario,
>>
>> Mario Ivankovits wrote:
>>
>>> I wont say that there aren't other ways to solve that, but using
>>> simple
>>> inheritance and instanceof is not the correct way.
>>
>> +1
>>
>> The current solution is somewhat unconventional, but this way you
>> always
>> know exactly which options are available for your FS.
>
> That argument doesn't fly. You'd get that from inheritance too.
>
>>
>>> Hmmm ... what I can think of is to refactor things that way:
>>>
>>> * FileSystemOptions holds just a map of configurations like
>>> Map<Class,
>>> FileSystemOption> * FileSystemOptions.set(Class vfsFilesystemClass,
>>> FileSystemOption options)
>>>
>>> FileSystemOption then can be a concrete instance of a set of
>>> configurations for one specific filesystem, so you might have
>>> HttpFileSystemOption, SftpFileSystemOption etc. Each of them
>>> holding all
>>> possible filesystem options.
>>>
>>> Sure, this completely breaks backward compatibility - and the
>>> GlobalFileSystemOptions thing needs to be solved somehow.
>>
>> This already exists with the DefaultFileSystemConfigBuilder that
>> provides
>> the UserAuthenticator. We actually derived from this class
>
> which class? DefaultFileSystemConfigBuilder or UserAuthenticator?
Some code helps more that a 1000 words:
=============== %< ====================
public class VFSConfigBuilder extends DefaultFileSystemConfigBuilder
{
private static final VFSConfigBuilder BUILDER = new VFSConfigBuilder();
public static VFSConfigBuilder getInstance()
{
return BUILDER;
}
public void setId(final FileSystemOptions opts, final String id) throws
FileSystemException
{
setParam(opts, "id", id);
}
@Override
protected Class<? extends FileSystemConfigBuilder> getConfigClass()
{
return VFSConfigBuilder.class;
}
}
=============== %< ====================
And despite your comment to Mario, I can overload the static method with a
new return type. Welcome to Java 5 :) Maybe we should switch for VFS 2.0
anyway ...
>> to provide an
>> additional id as system option - simply to control which FileSystem
>> instances are shared (hashCode of the FileSystemOptions is part of
>> this
>> decision).
>
> I'm not sure I understand this. Sample code would help. But I would
> imagine something could be put in place to control which file systems
> can be combined using the method Mario proposed above.
A snippet from the AbstractFileProvider:
=============== %< ====================
/**
* Adds a file system to those cached by this provider. The file system
* may implement {...@link VfsComponent}, in which case it is initialised.
*/
protected void addFileSystem(final Comparable key, final FileSystem fs)
throws FileSystemException
{
// Add to the cache
addComponent(fs);
FileSystemKey treeKey = new FileSystemKey(key,
fs.getFileSystemOptions());
((AbstractFileSystem) fs).setCacheKey(treeKey);
synchronized (this)
{
fileSystems.put(treeKey, fs);
}
}
/**
* Locates a cached file system
*
* @return The provider, or null if it is not cached.
*/
protected FileSystem findFileSystem(final Comparable key, final
FileSystemOptions fileSystemProps)
{
FileSystemKey treeKey = new FileSystemKey(key, fileSystemProps);
synchronized (this)
{
return (FileSystem) fileSystems.get(treeKey);
}
}
=============== %< ====================
The cache is also triggered by the FileSystemOptions since it is part of the
FileSystemKey. However, we use VFS in a JEE environment where we must have
some more control over the allocated resources. Currently we cannot close a
FileSystem, since it can be used in another thread/session. Unfortunately
we're faced now with the effect that over time VFS eats up any connection
to our SFTP server and never releases the connections. Since we use VFS to
perform some kind of batch process, we could easily release anything
related to this batch job right after it is done. Therefore we'd prefer a
controlled behaviour for this kind of caching.
- Jörg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
