cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Luigi Bai <>
Subject Re: [rfc] commons fileupload replacement
Date Mon, 08 Nov 2004 16:48:48 GMT

On Mon, 8 Nov 2004, Jorg Heymans wrote:

> Luigi Bai wrote:
>> Hi,
>> I'd like to point out that the Multipart support in Cocoon is one of the 
>> few things that isn't pluggable or replaceable. I'd like it to be possible 
>> to configure web.xml/CocoonServlet to take a class name that implements 
>> some MultipartParser interface, and keep Part as an interface (perhaps 
>> letting it evolve as different implementations are available).
> Point taken, but how many different implementations does a multipartparser 
> really need ? Commons-fileupload is RFC 1867 compliant, has disk and memory 
> based storage and is a "known and trusted" commons library.

Not many different ones are "needed". However, the current one is buggy, 
and it would have been much easier to replace for an end-user if it 
werent' so heavily embedded into the Servlet. If some problem turns up in 
commons-upload, or in your code, as a non-commit level end user I'm back 
in the same boat; I have to rewrite CocoonServlet to just fix it or hack 
it out. I *could* then make a PATCH to fix it, which would be forever 
ignored in Bugzilla. :-)

I find it hard to believe that we just saw Avalon/Excalibur/etc. implode, 
Carsten is rewriting core to get around it - I don't think it's reasonable 
to hard code another dependency at the class level. Since you're rewriting 
it anyway, how hard is it to abstract one level out?

>> Keeping the integration at the level of Interface means we don't run into 
>> the same kind of rigamarole that is going on with ECM etc.
> True, but we're talking about 5 isolated classes that deal with file uploads, 
> nothing more.

Well, it's your code.

View raw message