Re: [fileupload] RFC: Fileupload 1.3 or 2.0?
On 7/3/07, Stephen Colebourne <[EMAIL PROTECTED]> wrote: I've read the JIRA's and I don't understand why FileItem/Serializable is relevant. As such I'm struggling to understand this thread :-) It's a design problem. When the DiskFileItem is instantiated, the File isn't necessarily created yet. In other words, the DiskFileItem needs an internal reference to the FileCleaningTracker, which is unfortunately not Serializable. We could continue with ideas like making the FileCleaningTracker transient, but that would violate the contract that the library takes care of removing the temporary files. If there is a minor incompatible change, like making FileItem no longer implement Serializable, then IMO that can be a v2.0 with the same package name. (Minor means that it has no effect on the vast majority of users. In addition, deprecated methods and classes can be removed. If there are larger changes that involve design changes, especially changes to user code (backwards imcompatible) then that should be a v2.0 with a different package name. If you choose the latter option, I would personally prefer to see [fileupload] move to Java 1.5 at the same time. I think, what I intend would be closer to the first scenario. However, I am open for a package name change. I am also open for a move to Java 1.5 sources, because my experiences with retrotranslator are good. Jochen -- "Besides, manipulating elections is under penalty of law, resulting in a preventative effect against manipulating elections. The german government justifying the use of electronic voting machines and obviously believing that we don't need a police, because all illegal actions are forbidden. http://dip.bundestag.de/btd/16/051/1605194.pdf - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [fileupload] RFC: Fileupload 1.3 or 2.0?
Jochen Wiedmann wrote: when applying the fixes for IO-99 to commons-fileupload, I was originally under the impression, that this would be easily possible without any or at least with fully upward compliant API changes. Until I detected that for reasons, which absolutely escape me, someone made FileItem to implement the Serializable interface. I've read the JIRA's and I don't understand why FileItem/Serializable is relevant. As such I'm struggling to understand this thread :-) The longer I thought about it, the more I came to the conclusion, that the only clean solution is to accept API changes. In particular, let FileItem no longer implement the Serializable interface. While we are at it, we could as well dissolve the the FileItemFactory and the multipart parser. Remove the whole bunch of deprecated methods. In other words, I propose to resolve FILEUPLOAD-120.or FILEUPLOAD-125 finally by dropping binary compatibilty and declaring the next version as commons-fileupload 2.0, not 1.3. OK, here is my view on this (I'll get in early this time). If there is a minor incompatible change, like making FileItem no longer implement Serializable, then IMO that can be a v2.0 with the same package name. (Minor means that it has no effect on the vast majority of users. In addition, deprecated methods and classes can be removed. If there are larger changes that involve design changes, especially changes to user code (backwards imcompatible) then that should be a v2.0 with a different package name. If you choose the latter option, I would personally prefer to see [fileupload] move to Java 1.5 at the same time. Stephen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]