commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ben Speakmon" <bspeak...@apache.org>
Subject Re: RFC: Fileupload 1.3 or 2.0?
Date Tue, 03 Jul 2007 19:31:38 GMT
+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 <jochen.wiedmann@gmail.com> 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: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message