On Aug 18, 2009, at 11:29 PM, Jörg Schaible wrote:
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 ...
Apples and Oranges. The current minimum version is JDK 1.4. Since
WebDav is part of VFS it has to abide by that. But yes, if we change
the minimum JDK then that can be done.
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.
Yes, I'm familiar with that code. I was actually looking at it because
I had concerns that there could be problems with multiple users trying
to access the same file at the same time. Because of the code above
the issues I was worried about can't happen.
With the current design closing a FileSystem in a multithreaded system
cannot be done safely. There are race conditions that currently cannot
be avoided. SoftRefFilesCache used to call close and I commented it
out for that reason. Actually though, closing the FileSystem shouldn't
strictly be necessary to manage the connections. For example the Http
Provider uses a pool of connections. The pool size can certainly be
reduced and managed such that the connections are closed. I recently
had to implement a Provider to access a Subversion repository
(unfortunately, it can't reside at Apache due to the SVNKit license).
I ended up having to have each FileObject establish its own connection
to the repository. Perhaps the FTP provider(s) need to do something
similar.
Ralph
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
