Re: RFC: Fileupload 1.3 or 2.0?
On Wed, 2007-07-04 at 07:42 +0200, Jochen Wiedmann wrote: On 7/4/07, Martin Cooper [EMAIL PROTECTED] wrote: * We were already starting to clone classes from what was originally HttpClient and is now HttpComponents. One example is the ParameterParser class. When I saw HttpComponents being born, saw a lot of other stuff in there that FileUpload was doing, it looked like it would make a lot of sense to build FileUpload on top of HttpComponents, thus dramatically cutting down the amount of code necessary to build a FileUpload package. I agree with you on that it might make sense to reuse components from outside, if possible. Unfortunately HttpComponents (in the person of Oleg Kalnichevski) has repeatedly declared that he has no interest in adding a multipart parser to httpcomponents, which would be (IMO) the most important part. Instead he suggested to add such a parser to Commons Codec. I personally believe, that this extends the scope of Commons Codec. But yes, if possible, I'd still be interested to reuse another multipart parser. Do you know of any ASL licensed? Jochen You may want to take a look at Apache JAMES Mime4j [1] As to why we currently have no plans to provide support MIME coding in HttpComponents, there is more to it then just my trying to be difficult. We are simply precluded from developing content codecs by the project charter. It is one of several restrictions that were imposed on the project in order to secure an approval of the Jakarta PMC. However, given the fact that HttpComponents will most definitely have to leave Jakarta for another TLP or form a TLP of its own, the project charter may be revisited and revised. Having said that, I am still convinced HttpComponents ought not expand its scope beyond low level HTTP transport aspects and would prefer to work with other projects such as JAMES or Commons toward development of a set of transport independent content codecs. Oleg [1] http://james.apache.org/mime4j/index.html [2] http://svn.apache.org/repos/asf/jakarta/httpcomponents/project/project-charter.txt Thanks, Jochen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: RFC: Fileupload 1.3 or 2.0?
On 7/4/07, Oleg Kalnichevski [EMAIL PROTECTED] wrote: You may want to take a look at Apache JAMES Mime4j [1] Thanks for the hint, I'm gonna have a look on it. The streaming approach sounds good. -- 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]
RFC: Fileupload 1.3 or 2.0?
Hi, 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 can only guess, that someone had the idea to put a FileItem into the HttpSession. But resource tracking within a persistent HttpSession, seems to me to be clearly outside the scope of commons-fileupload. At least, this doesn't fit into the default implementation, which assumes temporary files, for good reasons. At first, I have attempted to fix the problem by making the FileCleaner serializable, but Rahul has rightly pointed out, that I am doing nonsense. See http://www.nabble.com/Re%3A--io--fileupload--svn-commit%3A-r518770---in--jakarta-commons-proper-io-trunk-src%3A-java-org-apache-commons-io-FileCleaningTracker.java-test-org-apache-commons-io-FileUtilsCleanDirectoryTestCase.java-p9520876.html for details. I have reverted the changes in commons-io and rethought my approach. 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. I know that others (in particular Martin) had bigger plans for 2.0: Reimplement the thing based on httpcomponents, or commons-codec, or whatever, and stuff like that. Unfortunately I see noone who'd be ready to do that. In particular, not me. Thoughts? 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: RFC: Fileupload 1.3 or 2.0?
+1. Removing deprecations is a worthy cause for a major release in and of itself. In fact, I'd suggest that removing deprecated and/or obviously wrong code is a necessary precursor to a redesign. Plus redesigns always scare me, since you never seem to get what you were expecting. :) On 7/3/07, Jochen Wiedmann [EMAIL PROTECTED] wrote: Hi, 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 can only guess, that someone had the idea to put a FileItem into the HttpSession. But resource tracking within a persistent HttpSession, seems to me to be clearly outside the scope of commons-fileupload. At least, this doesn't fit into the default implementation, which assumes temporary files, for good reasons. At first, I have attempted to fix the problem by making the FileCleaner serializable, but Rahul has rightly pointed out, that I am doing nonsense. See http://www.nabble.com/Re%3A--io--fileupload--svn-commit%3A-r518770---in--jakarta-commons-proper-io-trunk-src%3A-java-org-apache-commons-io-FileCleaningTracker.java-test-org-apache-commons-io-FileUtilsCleanDirectoryTestCase.java-p9520876.html for details. I have reverted the changes in commons-io and rethought my approach. 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. I know that others (in particular Martin) had bigger plans for 2.0: Reimplement the thing based on httpcomponents, or commons-codec, or whatever, and stuff like that. Unfortunately I see noone who'd be ready to do that. In particular, not me. Thoughts? 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]
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: RFC: Fileupload 1.3 or 2.0?
On 7/3/07, Jochen Wiedmann [EMAIL PROTECTED] wrote: Hi, 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. Ah, history... Commons FileUpload originated as part of the Turbine framework long, long ago. When it first came to Commons, FileItem extended javax.activation.DataSource, I believe to allow Turbine to directly e-mail uploaded files using JavaMail. In one of my early clean-up sprees, and after some discussion with Turbine folks, I removed the extension of DataSource but left the methods that are defined on DataSource, so that creating a FileItem extension that implemented DataSource was a trivial task. About 6 months after that, a patch supplied by Jon Stevens (of Turbine) was applied that added the extension of Serializable. This was presumably for Turbine compatibility, but I wasn't the person who committed the change, the log message from the person who did was a somewhat unhelpful PATH ( :) ) from Jon Scott Stevens, my memory isn't good enough to recall an associated thread (this was in 2002), and I'm too lazy to trawl the archives right now to find out if it was discussed at the time. ;-) I can only guess, that someone had the idea to put a FileItem into the HttpSession. But resource tracking within a persistent HttpSession, seems to me to be clearly outside the scope of commons-fileupload. At least, this doesn't fit into the default implementation, which assumes temporary files, for good reasons. At first, I have attempted to fix the problem by making the FileCleaner serializable, but Rahul has rightly pointed out, that I am doing nonsense. See http://www.nabble.com/Re%3A--io--fileupload--svn-commit%3A-r518770---in--jakarta-commons-proper-io-trunk-src%3A-java-org-apache-commons-io-FileCleaningTracker.java-test-org-apache-commons-io-FileUtilsCleanDirectoryTestCase.java-p9520876.html for details. I have reverted the changes in commons-io and rethought my approach. 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. I know that others (in particular Martin) had bigger plans for 2.0: Reimplement the thing based on httpcomponents, or commons-codec, or whatever, and stuff like that. Unfortunately I see noone who'd be ready to do that. In particular, not me. Yeah, I did, and no, I'm not likely to be jumping in at this particular point in time. My original thoughts, to the extent that I can remember them (it was quite a while ago!), were: * We were already starting to clone classes from what was originally HttpClient and is now HttpComponents. One example is the ParameterParser class. When I saw HttpComponents being born, saw a lot of other stuff in there that FileUpload was doing, it looked like it would make a lot of sense to build FileUpload on top of HttpComponents, thus dramatically cutting down the amount of code necessary to build a FileUpload package. * I wanted to reorganise the package structure, for a variety of reasons. The interfaces needed separating from implementations, and we needed to allow for multiple implementations, of different types. Yes, I know we have most of that now. We didn't, originally, and I ended up dealing with it while more or less retaining the original structure and just adding more structure on top of that. There's still a bunch of litter lying around that could do with cleaning up (il.e. removing) in a 2.0 release, though. Also, it would still be good to have a much more clear distinction between what is supposed to be public and what is not. (For example, recall the MultipartStream threads from not so long ago.) * I wanted to add a servlet filter along with multiple associated configuration implementations, so that we could provide much more of a drop-in capability, rather than requiring so much explicit integration into most consumer applications and frameworks. I actually went quite far down that path, and might even still have the code lying around somewhere, if anyone wanted to pick that up and finish it. That's about all I can think of right now, although I suspect there was more. I'll post again if I remember anything else. Oh, and I'm definitely in favour of going for a 2.0 release and cleaning up some crud along the way. I just don't think I'll be in a position to help any time soon, I'm afraid. -- Martin
Re: RFC: Fileupload 1.3 or 2.0?
On 7/4/07, Martin Cooper [EMAIL PROTECTED] wrote: * We were already starting to clone classes from what was originally HttpClient and is now HttpComponents. One example is the ParameterParser class. When I saw HttpComponents being born, saw a lot of other stuff in there that FileUpload was doing, it looked like it would make a lot of sense to build FileUpload on top of HttpComponents, thus dramatically cutting down the amount of code necessary to build a FileUpload package. I agree with you on that it might make sense to reuse components from outside, if possible. Unfortunately HttpComponents (in the person of Oleg Kalnichevski) has repeatedly declared that he has no interest in adding a multipart parser to httpcomponents, which would be (IMO) the most important part. Instead he suggested to add such a parser to Commons Codec. I personally believe, that this extends the scope of Commons Codec. But yes, if possible, I'd still be interested to reuse another multipart parser. Do you know of any ASL licensed? Also, it would still be good to have a much more clear distinction between what is supposed to be public and what is not. (For example, recall the MultipartStream threads from not so long ago.) Agreed. I was surprised to hear that the multipart parser *is* being reused. Oh, and I'm definitely in favour of going for a 2.0 release and cleaning up some crud along the way. I just don't think I'll be in a position to help any time soon, I'm afraid. As expected, but sad to hear anyways. :-) Thanks, 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]
