cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Antonio Gallardo" <agalla...@agssa.net>
Subject Re: [rfc] commons fileupload replacement
Date Mon, 08 Nov 2004 08:46:30 GMT
Jorg Heymans dijo:
> Hi,
>
> I have provided a patch [1] that removes cocoon's multipart upload
> parser with one based on commons-fileupload.
>
> My approach breaks existing client code however, so Antonio suggested to
> get a few more opinions before continueing.
>
> 1) Part, PartOnDisk, PartInMemory are not necessary anymore. They are
> replaced by the FileItem interface of commons fileupload. It should be
> doable to wrap the FileItems in a Part class as suggested by Reinhard
> (with a slight change to the contract, see  [1] ) .
>
> 2) web.xml parameter "overwrite-uploads" is gone. Instead, we need a
> parameter like "where-to-store-uploads" with values "disk" or "memory".
> In addition to this (not included in the patch) commons-fileupload
> offers a "threshold" for memory based storage, files larger than the
> threshold will get written to disk anyway - we don't *have* to use this
> however.
>
> 3) There is no replacement for getHeaders() in Part.java.
>
> The nice thing to do would be to deprecate the Part classes, and wrap
> the FileItem interface inside Part for 2.1.6. , remove Part in 2.1.7?
>
> Or is 2.1.6 too soon for this?
>
> Thoughts?
> Jorg
>
> [1] http://nagoya.apache.org/bugzilla/show_bug.cgi?id=32102

Hi Jorg:

Thanks for posting about that! :-D

Is posible to add support for both at the same time? If this is possible,
then we can add it in 2.1.6 and deprecate the old approach.

WDYT?

Best Regards,

Antonio Gallardo

Mime
View raw message