Mailing-List: contact dev-help@struts.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Struts Developers List" <dev@struts.apache.org>
Received-SPF: pass (nike.apache.org: domain of mfncooper@gmail.com designates
 209.85.223.176 as permitted sender)
MIME-Version: 1.0
Sender: mfncooper@gmail.com
In-Reply-To: <BLU0-SMTP21144AFFC398BCE23753478DF6D0@phx.gbl>
References: <BLU0-SMTP21144AFFC398BCE23753478DF6D0@phx.gbl>
Date: Wed, 14 Nov 2012 20:19:59 -0800
Message-ID: 
 <CAGEtHiJNeOR5WCukv4o9t8tW5LTkHQ=2Sbo2jzse=3xEJMDs7g@mail.gmail.com>
Subject: Re: processing of multipart request
From: Martin Cooper <martinc@apache.org>
To: Struts Developers List <dev@struts.apache.org>
Content-Type: multipart/alternative; boundary=f46d044630d2d6989d04ce80f644

--f46d044630d2d6989d04ce80f644
Content-Type: text/plain; charset=ISO-8859-1

On Mon, Nov 12, 2012 at 4:39 AM, Fastupload <fastupload@outlook.com> wrote:

> To who maybe concern,
>
> I just notice struts2 framework parses multipart/form-data requesting into
> a temporary file, and marshal a java.io.File object for struts2 action
> regarding file input of multipart-form data request. also the framework
>  parses all files in request and then make a filter rule in
> FileUploadInterceptor.java. And finally, framework clean temporary files
> after action is invoked.
>
> Following the processing, there are three disadvantages:
> 1, use temporary file makes low performance
> 2, redundancy operation --  clean up temporary file
> 3, struts action only supports java.io.File class to represent a uploading
> file in multipart/form-data request.
> 4, filter all file after parsing has been done, the action may be prior to
> interceptors.
>

All of those could be addressed without switching to a new file upload
framework, since Commons FileUpload supports them. It would seem to make
more sense to me to expand what we have already, rather than throw it out
and replace it with something new and untested (i.e. not in widespread
Struts production usage).

Could you guys have a look into *fastupload* open source project in
> https://sourceforge.net/projects/fastupload. Right now it is the fastest
> form-based upload parsing component in java area. it makes a significant
> performance improvement and advance features, such as,
> 1, 2.x faster than Apache Commons FileUpload in stream method. certainly,
> it's 5.x faster than apache commons file upload in disk method.
>

Please provide some links to the benchmarks you've run to measure those
things, and the constraints you used when measuring them.


> 2, filter boundaries with determining MIME and file name in advance.
>
>
>
> In fastupload-0.4.7 version, it has released some codes that work with
> struts2 framework, enable parsing files with it in struts2 framework.  To
> improve features of struts2 multipart/form-data request, Could you consider
> to integrate *fastupload* source code into struts2 framework.  incurring
> struts2 supports both *fastupload* and ASF commons file upload?
>

I can't find any reference to Struts in the codebase you provided a link
to. Perhaps you could provide a reference to the Struts related code?

The right approach to integration is basically what Wes originally
suggested. It should be usable as a plugin. If changes need to be made to
Struts to support that, you can propose those changes for consideration. If
they're accepted, then people will be able to choose your fastupload as an
alternative to what's there today, if they choose to do so for their
application.

By the way, your code is hard to check out because of the messed up
repository structure, and there are also several typos even in the
interface and method names. Those things detract from any confidence in the
quality of your code, so you might want to clean them up.

--
Martin Cooper


best wishes,
> Link Qian
>
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>

--f46d044630d2d6989d04ce80f644--