Re: svn commit: r805384 - /commons/proper/vfs/trunk/core/src/main/java/org/apache/commons/vfs/FileSystemOptions.java
On 18/08/2009, joe...@apache.org joe...@apache.org wrote: Author: joehni Date: Tue Aug 18 12:22:35 2009 New Revision: 805384 URL: http://svn.apache.org/viewvc?rev=805384view=rev Log: Make FileSystemOptions cloneable (VFS-278). Modified: commons/proper/vfs/trunk/core/src/main/java/org/apache/commons/vfs/FileSystemOptions.java Modified: commons/proper/vfs/trunk/core/src/main/java/org/apache/commons/vfs/FileSystemOptions.java URL: http://svn.apache.org/viewvc/commons/proper/vfs/trunk/core/src/main/java/org/apache/commons/vfs/FileSystemOptions.java?rev=805384r1=805383r2=805384view=diff == --- commons/proper/vfs/trunk/core/src/main/java/org/apache/commons/vfs/FileSystemOptions.java (original) +++ commons/proper/vfs/trunk/core/src/main/java/org/apache/commons/vfs/FileSystemOptions.java Tue Aug 18 12:22:35 2009 @@ -29,7 +29,7 @@ * @see org.apache.commons.vfs.provider.sftp.SftpFileSystemConfigBuilder * @see org.apache.commons.vfs.provider.ftp.FtpFileSystemConfigBuilder */ -public class FileSystemOptions +public class FileSystemOptions implements Cloneable { /** The options */ private Map options = new TreeMap(); @@ -161,5 +161,14 @@ // TODO: compare Entry by Entry return 0; } + +/** + * {...@inheritdoc} + */ +public Object clone() { +FileSystemOptions clone = new FileSystemOptions(); +clone.options = new TreeMap(options); +return clone; +} This clone() does not call super.clone() so won't work properly for sub-classes. } - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: svn commit: r805384 - /commons/proper/vfs/trunk/core/src/main/java/org/apache/commons/vfs/FileSystemOptions.java
Hi Sebb, sebb wrote at Dienstag, 18. August 2009 14:48: + +/** + * {...@inheritdoc} + */ +public Object clone() { +FileSystemOptions clone = new FileSystemOptions(); +clone.options = new TreeMap(options); +return clone; +} This clone() does not call super.clone() so won't work properly for sub-classes. I know, but since the key of the map is a private class anyway, it does not make too much sense to derive from FileSystemOptions anyway ... don't you think? - Jörg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: svn commit: r805384 - /commons/proper/vfs/trunk/core/src/main/java/org/apache/commons/vfs/FileSystemOptions.java
On 18/08/2009, Jörg Schaible joerg.schai...@gmx.de wrote: Hi Sebb, sebb wrote at Dienstag, 18. August 2009 14:48: + +/** + * {...@inheritdoc} + */ +public Object clone() { +FileSystemOptions clone = new FileSystemOptions(); +clone.options = new TreeMap(options); +return clone; +} This clone() does not call super.clone() so won't work properly for sub-classes. I know, but since the key of the map is a private class anyway, it does not make too much sense to derive from FileSystemOptions anyway ... don't you think? In that case, you could make the class final. In any case, it would be helpful to document that the clone() method is not written to be sub-classable. - Jörg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: svn commit: r805384 - /commons/proper/vfs/trunk/core/src/main/java/org/apache/commons/vfs/FileSystemOptions.java
On Tue, Aug 18, 2009 at 7:48 AM, sebb seb...@gmail.com wrote: On 18/08/2009, Jörg Schaible joerg.schai...@gmx.de wrote: Hi Sebb, sebb wrote at Dienstag, 18. August 2009 14:48: + +/** + * {...@inheritdoc} + */ +public Object clone() { +FileSystemOptions clone = new FileSystemOptions(); +clone.options = new TreeMap(options); +return clone; +} This clone() does not call super.clone() so won't work properly for sub-classes. I know, but since the key of the map is a private class anyway, it does not make too much sense to derive from FileSystemOptions anyway ... don't you think? In that case, you could make the class final. In any case, it would be helpful to document that the clone() method is not written to be sub-classable. I actually don't agree that FileSystemOptions shouldn't be subclassed. I have always disliked immensely having to manipulate FileSystemOptions using a ConfigBuilder class. From personal experience, I've found working with it to be awkward and brittle. I would much prefer to have each provider subclass FileSystemOptions and provide the getters and setters there. Then, at least, you could do an instanceof on the FileSystemOptions and determine what options are actually supposed to be there. Ralph
RE: svn commit: r805384 - /commons/proper/vfs/trunk/core/src/main/java/org/apache/commons/vfs/FileSystemOptions.java
Hi! From personal experience, I've found working with it to be awkward and brittle. I would much prefer to have each provider subclass FileSystemOptions and provide the getters and setters there. Then, at least, you could do an instanceof on the FileSystemOptions and determine what options are actually supposed to be there. Look, The FileSystemOptions holds options for various filesystem implementations - at the same time! The reason for this is, that, given the url is provided by the user, you simply do not know which real implementation will be used. Thus, you have to provide e.g. ftp settings and sftp settings at the same time and let VFS decide which options to use - depending on the URL provided by the user. Why would you like to pass in an option-set using a concrete config class if the URL is anything else then concrete. Also, a layered filesystem might require different settings e.g. compression-level of a zip-file on an ftp share. This might require you to configure the zip filesystem (compression) AND the ftp filesystem (active/passive mode) Also, the idea was to implement some sort of GlobalFileSystemOptions, the filesystem implementation then does not need to be changed, just the FileSystemOptions have to take care of that. IF you use the options in a way which allows you to know which kind of filesystem will be used - good - but then the builder is just another layer, but not awkward and brittle I think. I wont say that there aren't other ways to solve that, but using simple inheritance and instanceof is not the correct way. Hmmm ... what I can think of is to refactor things that way: * FileSystemOptions holds just a map of configurations like MapClass, 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. Ciao, Mario - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [net] trunk vs branches
On Thu, Aug 13, 2009 at 11:08 AM, Stefan Bodewigbode...@apache.org wrote: Hi, over in Ant land we've received a bug report that Ant's ftp task wouldn't compile against commons-net 2,0 because the IMAGE_FILE_TYPE constant was removed from the FTP class. Given that trunk still has that constant, is trunk in net sort of obsolete and we should consider one of the branches as its tip? If so, should we change Gump to build from one of the branches? Now Net 2.0 has been released we should IMO switch the trunk and branch. Gump would have told us about the breakage, which may have been important for net as well since the constant has never been deprecated and the migration howto claims no changes necessary which is obviously not true. From memory some classes moved package as well. Niall Stefan - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: svn commit: r805384 - /commons/proper/vfs/trunk/core/src/main/java/org/apache/commons/vfs/FileSystemOptions.java
sebb wrote: On 18/08/2009, Jörg Schaible joerg.schai...@gmx.de wrote: Hi Sebb, sebb wrote at Dienstag, 18. August 2009 14:48: + +/** + * {...@inheritdoc} + */ +public Object clone() { +FileSystemOptions clone = new FileSystemOptions(); +clone.options = new TreeMap(options); +return clone; +} This clone() does not call super.clone() so won't work properly for sub-classes. I know, but since the key of the map is a private class anyway, it does not make too much sense to derive from FileSystemOptions anyway ... don't you think? In that case, you could make the class final. In any case, it would be helpful to document that the clone() method is not written to be sub-classable. You're right, it should be at least consistent. Committed. - Jörg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
RE: svn commit: r805384 - /commons/proper/vfs/trunk/core/src/main/java/org/apache/commons/vfs/FileSystemOptions.java
Hi Mario, Mario Ivankovits wrote: Hi! From personal experience, I've found working with it to be awkward and brittle. I would much prefer to have each provider subclass FileSystemOptions and provide the getters and setters there. Then, at least, you could do an instanceof on the FileSystemOptions and determine what options are actually supposed to be there. Look, The FileSystemOptions holds options for various filesystem implementations - at the same time! The reason for this is, that, given the url is provided by the user, you simply do not know which real implementation will be used. Thus, you have to provide e.g. ftp settings and sftp settings at the same time and let VFS decide which options to use - depending on the URL provided by the user. Why would you like to pass in an option-set using a concrete config class if the URL is anything else then concrete. Also, a layered filesystem might require different settings e.g. compression-level of a zip-file on an ftp share. This might require you to configure the zip filesystem (compression) AND the ftp filesystem (active/passive mode) Also, the idea was to implement some sort of GlobalFileSystemOptions, the filesystem implementation then does not need to be changed, just the FileSystemOptions have to take care of that. IF you use the options in a way which allows you to know which kind of filesystem will be used - good - but then the builder is just another layer, but not awkward and brittle I think. 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. Hmmm ... what I can think of is to refactor things that way: * FileSystemOptions holds just a map of configurations like MapClass, 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 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). - Jörg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: svn commit: r805384 - /commons/proper/vfs/trunk/core/src/main/java/org/apache/commons/vfs/FileSystemOptions.java
On Aug 18, 2009, at 10:18 AM, Mario Ivankovits wrote: Hi! From personal experience, I've found working with it to be awkward and brittle. I would much prefer to have each provider subclass FileSystemOptions and provide the getters and setters there. Then, at least, you could do an instanceof on the FileSystemOptions and determine what options are actually supposed to be there. Look, The FileSystemOptions holds options for various filesystem implementations - at the same time! The reason for this is, that, given the url is provided by the user, you simply do not know which real implementation will be used. Thus, you have to provide e.g. ftp settings and sftp settings at the same time and let VFS decide which options to use - depending on the URL provided by the user. Why would you like to pass in an option-set using a concrete config class if the URL is anything else then concrete. Also, a layered filesystem might require different settings e.g. compression-level of a zip-file on an ftp share. This might require you to configure the zip filesystem (compression) AND the ftp filesystem (active/passive mode) Also, the idea was to implement some sort of GlobalFileSystemOptions, the filesystem implementation then does not need to be changed, just the FileSystemOptions have to take care of that. IF you use the options in a way which allows you to know which kind of filesystem will be used - good - but then the builder is just another layer, but not awkward and brittle I think. No. They are awkward and brittle. WebDavFileSystemConfigBuilder extends HttpFileSystemConfigBuilder. The getInstance method has to return an HttpFileSystemConfigBuilder since you can't change the return value of an overridden method. So code calling getInstance has to then cast it to the correct type to use it. Of course, The name of the method could have been changed but then it would be instantiated differently then every other ConfigBuilder. I wont say that there aren't other ways to solve that, but using simple inheritance and instanceof is not the correct way. Hmmm ... what I can think of is to refactor things that way: * FileSystemOptions holds just a map of configurations like MapClass, 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. I actually like this a lot more than the current implementation. However, it wouldn't allow the get and set methods to be exposed at compile time on the root FileSystemOptions class. I think that can be worked around pretty easily. Sure, this completely breaks backward compatibility - and the GlobalFileSystemOptions thing needs to be solved somehow. The ConfigBuilders can be deprecated and I'm pretty sure they can be made to interact with this structure fairly easily. - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org