commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Martin Cooper" <>
Subject Re: RFC: Fileupload 1.3 or 2.0?
Date Wed, 04 Jul 2007 03:11:27 GMT
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.

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
> 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 Cooper

> 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