commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jörg Schaible <joerg.schai...@gmx.de>
Subject Re: svn commit: r805384 - /commons/proper/vfs/trunk/core/src/main/java/org/apache/commons/vfs/FileSystemOptions.java
Date Wed, 19 Aug 2009 08:17:54 GMT
Ralph Goers wrote at Mittwoch, 19. August 2009 09:16:

> 
> 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.

Actually I spoke too soon. To make the implementation above work, I have to
replace the INSTANCE of the DefaultFileSystemConfigBuilder, since VFS
internally uses DefaultFileSystemConfigBuilder.getInstance() to access the
UserAuthenticator. It does not help me if I derive from that config
builder :-/

So it seems that you've been right looking for an alternative
implementation ...

[snip]

> 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.

Yes, I also looked into that part, but I could not find a way to decouple
this for SFTP from the outside. Current implementation of the SFTP provider
ties the FS to the connection.

> 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.

Definitely.

- Jörg


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


Mime
View raw message