commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jochen Wiedmann <>
Subject Re: [FILEUPLOAD] RfC: Proposed API changes for streaming
Date Sun, 11 Jun 2006 21:16:31 GMT
Martin Cooper wrote:

> Let's hope. ;-) Please add youself to the list of developers in the
> project.xml file.


> This looks interesting. However, given the non-trivial nature of the
> changes, and the "stylistic" effect on the way FileUpload works, I
> wonder if
> this wouldn't be better incorporated into the FileUpload 2 design, rather
> than being retrofitted into FileUpload 1.x.

I am open for both. In either way, we can start in a branch. That leaves
everything open, doesn't it? I have one concern, though: Please let's try to
have a at least a beta release within short time, say three months?

> Well, I guess I don't agree here. If FileItem extended  SimFileItem, then I
> could pass a FileItem to methods that accept a SlimFileItem. At that point,
> that SlimFileItem may or may not throw an exception if getInputStream is
> called more than once. That's bad API behaviour.

Personally I have no problem with my suggestion: If a method would accept a
StreamingFileItem, then that method should not expect, that getInputStream()
cannot be used more than once, so that's okay.

However, let's say that FileItem doesn't extend StreamingFileItem. Fine with me.

> SlimFileItem is best implemented as an inner class of the MultipartStream.
> Hmm. Not if you expect to expose SlimFileItem as part of the public API,
> which you are suggesting with the getItemIterator method below.

That's something I do not understand. The StreamingFileItem is an interface,
which is exposed. What's the problem, if the implementation is an inner class?

> Multipartstream isn't (supposed to be) part of the public API, so exposing
> an inner class of it through the public API is a no-no.

That's good to know. I get you right, that this means we may change that
classes API, may we?

> No. A FileUploadException isn't always related to IO, so extending
> IOException would simply be wrong.


Attached you find a proposed patch, that takes a first step: The
MultipartStream receives an inner class ItemInputStream. This inner class is
used by readBodyData. (Obviously, the same InputStream will later be
returned by the StreamingFileItem.)


View raw message