commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ben Speakmon" <>
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 <> 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
> 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.
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

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