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-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
