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