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 19:05:55 GMT

On Mon, 8 Nov 2004, Geoff Howard wrote:
> On Mon, 8 Nov 2004 08:20:56 -0600 (CST), Luigi Bai
> <> wrote:
>> 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).
> Some historical/background points (with the caveat that some changes
> have happened due to CForms that I have not paid full attention to):
> - We also have tried to avoid anti-patterns like "over
> componentization" i.e., making things pluggable that really don't need
> to be, which was probably judged to be the case here (though see
> below).
> - There were other grander plans for request handling.  In particular,
> see the "Pluggable Request Factories" of Stefano's RT here:
> - You'll notice a third point in the RT above: our "pluggable" problem
> extends beyond multipart uploads.  It includes things like WebDAV and

Good points.

>> 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, although another major lesson learned from ECM was that external
> communities can also let you down.  The last time I monitored the
> commons list, I didn't get warm fuzzies about the politics and health
> there, for what that's worth.

That's precisely what I mean...

>> By the way, I'm not clear on why Multipart support can't be implemented as
>> an Action? If it's an Action, then it's clearly pluggable, and all this
>> goes away. Why is it so early in the process, hard coded in CocoonServlet?
> - Actions were a muddy concept that have been or can be at least
> partially if not fully replaced by other items.
> - Why so early in the process is another good question.  Two reasons I
> remember are:
> 1) Cocoon is not only a CocoonServlet but also runs in different
> environments (Command Line for example) where multipart requests do
> not have exact parallel if they exist at all.  We have tried to avoid
> dependencies on Servlet specific APIs in part due to this issue.
> Combined with the fact that Cocoon's uri abstraction (all uris are
> mapped to the CocoonServlet, making total control in sitemap possible)
> makes it possible that relying on Commons upload may turn out to be a
> bad idea in the end: they do not have the same complexity of concerns.
> In fact, they've had some recent refactoring there to accomodate
> portlet environments.  If someone can give an analysis of whether this
> helps us or hurts us with respect to our complex needs, that would be
> a big plus.
> 2) The cocoon framework as many frameworks pre-parses the request to
> make all parameters available to the pipeline semantics.  The plan of
> adaptRequest was to allow this to take place for most parameters up
> front, but the multipart bits later.  The work to do this was never
> done.

Ah, a generic request adaptation framework.

> Any patch that addresses all these concerns would probably get some
> good attention.
> Short of that, a patch that provides backwards compatibility by
> wrapping the commons library is next best in my opinion.  Short of
> full pluggable request adaptors, encapsulation is as good as
> configurability in this case IMO.  In this case, I think people will
> be fine with one solution for the project, as long as it's easy to rip
> out and replace if necessary.

That's why I'm suggesting having an Interface and an init-param that 
allows you to load a class implementing that Interface. Right now if 
multipart is not fixed/patched (see below) in 2.1.6 then we need to 
"carry" this patch forward to the new source tree if/when we use 2.1.6. 
This is in contrast to almost anything else (Generators, Serializers, 
Transformers) that we just fork off into our own namespace, patch or 
extend, and pull out of our own jar at run time.

I suppose we could fork the whole CocoonServlet.

> Earlier someone noted the comment in the code about multipart/mixed.
> I am not an expert here, but when I looked into this some time ago, it
> was not supported by browsers.  We do support multiple files per form
> using multiple input elements, so full conformance with the spec would
> be academic.  Am I wrong here?
> Geoff

Not academic; see

We are using a script with "curl" to upload multiple files on one input 
element (this is for a list of images to a slide show style viewer).

View raw message