Re: processing of multipart request
Wes, I have read struts2 file upload framework and plugin guide about file upload. It requires the plugin provides a java.IO.File object to interceptors. so in the way, upload component has to use temporary file. it's not reasonable to better performance. Here are fast upload API usage and performance https://sourceforge.net/p/fastupload/wiki/Fastupload%20Home/ https://sourceforge.net/p/fastupload/wiki/Performance%20Comparison/ Link On Nov 16, 2012, at 6:40 PM, Rene Gielen rgie...@apache.org wrote: Going to write a plugin should really be the way to go, as Wes and Martin already pointed out. There is positive experience with successful externally maintained Struts 2 plugins such as Struts 2 jQuery e.g. We also provide a platform for Struts 2 developers to stay in touch with latest plugin developments, internally or externally maintained: https://cwiki.apache.org/confluence/display/S2PLUGINS/Home Regard, - René Am 12.11.12 16:13, schrieb Wes Wannemacher: Another approach would be for you to take a look at our plugin API and build a plugin for integrating your framework into a Struts 2 web-app. -Wes On Mon, Nov 12, 2012 at 7:39 AM, Fastupload fastupl...@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. 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. 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? best wishes, Link Qian - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org -- René Gielen http://twitter.com/rgielen - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
Re: processing of multipart request
Link, I believe that what suggested by others is good way to go, you can easily create a plugin using fastupload. one of best feature of S2 is its flexibility to enhance and provide added features using plugins. Thanks Umesh On Sat, Nov 17, 2012 at 3:43 PM, Fastupload fastupl...@outlook.com wrote: Wes, I have read struts2 file upload framework and plugin guide about file upload. It requires the plugin provides a java.IO.File object to interceptors. so in the way, upload component has to use temporary file. it's not reasonable to better performance. Here are fast upload API usage and performance https://sourceforge.net/p/fastupload/wiki/Fastupload%20Home/ https://sourceforge.net/p/fastupload/wiki/Performance%20Comparison/ Link On Nov 16, 2012, at 6:40 PM, Rene Gielen rgie...@apache.org wrote: Going to write a plugin should really be the way to go, as Wes and Martin already pointed out. There is positive experience with successful externally maintained Struts 2 plugins such as Struts 2 jQuery e.g. We also provide a platform for Struts 2 developers to stay in touch with latest plugin developments, internally or externally maintained: https://cwiki.apache.org/confluence/display/S2PLUGINS/Home Regard, - René Am 12.11.12 16:13, schrieb Wes Wannemacher: Another approach would be for you to take a look at our plugin API and build a plugin for integrating your framework into a Struts 2 web-app. -Wes On Mon, Nov 12, 2012 at 7:39 AM, Fastupload fastupl...@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. 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. 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? best wishes, Link Qian - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org -- René Gielen http://twitter.com/rgielen - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org -- With Regards Umesh Awasthi http://www.travellingrants.com/
Re: processing of multipart request
Umesh,
thanks for your reply! Based on current file upload framework to write a
plugin. it only support java.io.File, for example, the Action has to use File
object to access multipart data of HTTP request. why not we do access multipart
data directly and efficiently, in stead of temporary file?
so I think we need to refactor current file upload framework in S2 to support
more efficient way. the new file upload framework has the ability that enable
user config his prefered file upload component and processing way.
this is current form of Action access multipart data
public class StrutUploadAction2 extends ActionSupport {
private File photo;
@Override
public String execute() throws Exception {
// …
return super.execute();
}
}
But the efficient way is this or next ..
public class StrutUploadAction1 extends ActionSupport {
private MultiPartFile photo;
private String description;
@Override
public String execute() throws Exception {
// .. ..
return super.execute();
}
}
for more information please look at
https://sourceforge.net/p/fastupload/wiki/Fastupload%20Home/
or
-
public class StrutUploadAction2 extends ActionSupport {
private FileItemStream photo;
@Override
public String execute() throws Exception {
/ /…
return super.execute();
}
}
// in ASF commons fileupload, FileItemStream contains multipart data in
memory… for more information, please look at
http://commons.apache.org/fileupload/streaming.html
Best Wishes,
Link Qian
On Nov 17, 2012, at 6:18 PM, Umesh Awasthi umeshawas...@gmail.com wrote:
Link,
I believe that what suggested by others is good way to go,
you can easily create a plugin using fastupload.
one of best feature of S2 is its flexibility to enhance and provide added
features using plugins.
Thanks
Umesh
On Sat, Nov 17, 2012 at 3:43 PM, Fastupload fastupl...@outlook.com wrote:
Wes,
I have read struts2 file upload framework and plugin guide about file
upload. It requires the plugin provides a java.IO.File object to
interceptors. so in the way, upload component has to use temporary file.
it's not reasonable to better performance.
Here are fast upload API usage and performance
https://sourceforge.net/p/fastupload/wiki/Fastupload%20Home/
https://sourceforge.net/p/fastupload/wiki/Performance%20Comparison/
Link
On Nov 16, 2012, at 6:40 PM, Rene Gielen rgie...@apache.org wrote:
Going to write a plugin should really be the way to go, as Wes and
Martin already pointed out. There is positive experience with successful
externally maintained Struts 2 plugins such as Struts 2 jQuery e.g.
We also provide a platform for Struts 2 developers to stay in touch with
latest plugin developments, internally or externally maintained:
https://cwiki.apache.org/confluence/display/S2PLUGINS/Home
Regard,
- René
Am 12.11.12 16:13, schrieb Wes Wannemacher:
Another approach would be for you to take a look at our plugin API and
build a plugin for integrating your framework into a Struts 2 web-app.
-Wes
On Mon, Nov 12, 2012 at 7:39 AM, Fastupload fastupl...@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.
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.
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*
Re: processing of multipart request
On Nov 17, 2012, at 5:13 AM, Fastupload fastupl...@outlook.com wrote: Here are fast upload API usage and performance https://sourceforge.net/p/fastupload/wiki/Performance%20Comparison/ It seems odd that these measurements start at 1MB...is it at least as fast for smaller files? On Nov 17, 2012, at 7:14 AM, Fastupload fastupl...@outlook.com wrote: the Action has to use File object to access multipart data of HTTP request. It doesn't *have* to. I don't recall whether the action property gets set by the core framework or an interceptor, but your plugin can use reflection to find the type that the appropriate setter is expecting, and then set the appropriate type of data. So to fully utilize your plugin, someone would have to include the plugin, possibly reconfigure the interceptor stack, and update the type their action expects. Importantly it should still work when the first two steps have been done, but not yet the third. -Dale - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
Re: processing of multipart request
On Sat, Nov 17, 2012 at 4:14 AM, Fastupload fastupl...@outlook.com wrote:
Umesh,
thanks for your reply! Based on current file upload framework to write a
plugin. it only support java.io.File, for example, the Action has to use
File object to access multipart data of HTTP request. why not we do access
multipart data directly and efficiently, in stead of temporary file?
so I think we need to refactor current file upload framework in S2 to
support more efficient way. the new file upload framework has the ability
that enable user config his prefered file upload component and processing
way.
Great. So do that. Provide a patch that refactors S2, such that the current
Commons FileUpload code is still the default, and such that an alternative,
like your fastupload plugin (but not restricted to it), can be configured
by the user if they want it. In your original post, you said you already
have that code, but I could not find it in your svn repo.
Please understand that there is no way that the existing code will be
*replaced* by a new implementation as the default any time soon. There are
tens of thousands of applications (S1, S2, and many others) that use
Commons FileUpload today, and have done for many, many years, so we know
that code is extremely robust. As far as I can tell, nobody else has ever
heard of fastupload before, and it certainly does not have the kind of
real-world testing that Commons FileUpload has had. If you want to provide
it as a plugin, people can experiment with it, and deploy it if they decide
they like it. But we are not going to throw out what has been solid for
years and replace it with something that hasn't been tested like Commons
FileUpload has.
--
Martin Cooper
this is current form of Action access multipart data
public class StrutUploadAction2 extends ActionSupport {
private File photo;
@Override
public String execute() throws Exception {
// …
return super.execute();
}
}
But the efficient way is this or next ..
public class StrutUploadAction1 extends ActionSupport {
private MultiPartFile photo;
private String description;
@Override
public String execute() throws Exception {
// .. ..
return super.execute();
}
}
for more information please look at
https://sourceforge.net/p/fastupload/wiki/Fastupload%20Home/
or
-
public class StrutUploadAction2 extends ActionSupport {
private FileItemStream photo;
@Override
public String execute() throws Exception {
/ /…
return super.execute();
}
}
// in ASF commons fileupload, FileItemStream contains multipart data in
memory… for more information, please look at
http://commons.apache.org/fileupload/streaming.html
Best Wishes,
Link Qian
On Nov 17, 2012, at 6:18 PM, Umesh Awasthi umeshawas...@gmail.com wrote:
Link,
I believe that what suggested by others is good way to go,
you can easily create a plugin using fastupload.
one of best feature of S2 is its flexibility to enhance and provide
added
features using plugins.
Thanks
Umesh
On Sat, Nov 17, 2012 at 3:43 PM, Fastupload fastupl...@outlook.com
wrote:
Wes,
I have read struts2 file upload framework and plugin guide about file
upload. It requires the plugin provides a java.IO.File object to
interceptors. so in the way, upload component has to use temporary file.
it's not reasonable to better performance.
Here are fast upload API usage and performance
https://sourceforge.net/p/fastupload/wiki/Fastupload%20Home/
https://sourceforge.net/p/fastupload/wiki/Performance%20Comparison/
Link
On Nov 16, 2012, at 6:40 PM, Rene Gielen rgie...@apache.org wrote:
Going to write a plugin should really be the way to go, as Wes and
Martin already pointed out. There is positive experience with
successful
externally maintained Struts 2 plugins such as Struts 2 jQuery e.g.
We also provide a platform for Struts 2 developers to stay in touch
with
latest plugin developments, internally or externally maintained:
https://cwiki.apache.org/confluence/display/S2PLUGINS/Home
Regard,
- René
Am 12.11.12 16:13, schrieb Wes Wannemacher:
Another approach would be for you to take a look at our plugin API and
build a plugin for integrating your framework into a Struts 2 web-app.
-Wes
On Mon, Nov 12, 2012 at 7:39 AM, Fastupload fastupl...@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
RE: processing of multipart request
for everyone's edification:
what would be the interfaces that Umesh must implement to write a proper
Struts2 plugin?Any changes to the interceptor stack?
Which test criteria should Umesh consider to validate the new FileUpload plugin
plays well with the (new and improved) interceptor stack? thanks,
Martin
Date: Sat, 17 Nov 2012 08:51:05 -0800
Subject: Re: processing of multipart request
From: mart...@apache.org
To: dev@struts.apache.org
On Sat, Nov 17, 2012 at 4:14 AM, Fastupload fastupl...@outlook.com wrote:
Umesh,
thanks for your reply! Based on current file upload framework to write a
plugin. it only support java.io.File, for example, the Action has to use
File object to access multipart data of HTTP request. why not we do access
multipart data directly and efficiently, in stead of temporary file?
so I think we need to refactor current file upload framework in S2 to
support more efficient way. the new file upload framework has the ability
that enable user config his prefered file upload component and processing
way.
Great. So do that. Provide a patch that refactors S2, such that the current
Commons FileUpload code is still the default, and such that an alternative,
like your fastupload plugin (but not restricted to it), can be configured
by the user if they want it. In your original post, you said you already
have that code, but I could not find it in your svn repo.
Please understand that there is no way that the existing code will be
*replaced* by a new implementation as the default any time soon. There are
tens of thousands of applications (S1, S2, and many others) that use
Commons FileUpload today, and have done for many, many years, so we know
that code is extremely robust. As far as I can tell, nobody else has ever
heard of fastupload before, and it certainly does not have the kind of
real-world testing that Commons FileUpload has had. If you want to provide
it as a plugin, people can experiment with it, and deploy it if they decide
they like it. But we are not going to throw out what has been solid for
years and replace it with something that hasn't been tested like Commons
FileUpload has.
--
Martin Cooper
this is current form of Action access multipart data
public class StrutUploadAction2 extends ActionSupport {
private File photo;
@Override
public String execute() throws Exception {
// …
return super.execute();
}
}
But the efficient way is this or next ..
public class StrutUploadAction1 extends ActionSupport {
private MultiPartFile photo;
private String description;
@Override
public String execute() throws Exception {
// .. ..
return super.execute();
}
}
for more information please look at
https://sourceforge.net/p/fastupload/wiki/Fastupload%20Home/
or
-
public class StrutUploadAction2 extends ActionSupport {
private FileItemStream photo;
@Override
public String execute() throws Exception {
/ /…
return super.execute();
}
}
// in ASF commons fileupload, FileItemStream contains multipart data in
memory… for more information, please look at
http://commons.apache.org/fileupload/streaming.html
Best Wishes,
Link Qian
On Nov 17, 2012, at 6:18 PM, Umesh Awasthi umeshawas...@gmail.com wrote:
Link,
I believe that what suggested by others is good way to go,
you can easily create a plugin using fastupload.
one of best feature of S2 is its flexibility to enhance and provide
added
features using plugins.
Thanks
Umesh
On Sat, Nov 17, 2012 at 3:43 PM, Fastupload fastupl...@outlook.com
wrote:
Wes,
I have read struts2 file upload framework and plugin guide about file
upload. It requires the plugin provides a java.IO.File object to
interceptors. so in the way, upload component has to use temporary file.
it's not reasonable to better performance.
Here are fast upload API usage and performance
https://sourceforge.net/p/fastupload/wiki/Fastupload%20Home/
https://sourceforge.net/p/fastupload/wiki/Performance%20Comparison/
Link
On Nov 16, 2012, at 6:40 PM, Rene Gielen rgie...@apache.org wrote:
Going to write a plugin should really be the way to go, as Wes and
Martin already pointed out. There is positive experience with
successful
externally maintained Struts 2 plugins such as Struts 2 jQuery e.g.
We also provide a platform for Struts 2 developers to stay in touch
with
latest plugin developments, internally or externally maintained:
https://cwiki.apache.org/confluence/display/S2PLUGINS/Home
Regard,
- René
Am 12.11.12 16:13,
Re: processing of multipart request
Martin,
I guess you mentioned me while it should be Link ;-)
Thanks
Umesh
On Sun, Nov 18, 2012 at 12:12 AM, Martin Gainty mgai...@hotmail.com wrote:
for everyone's edification:
what would be the interfaces that Umesh must implement to write a proper
Struts2 plugin?Any changes to the interceptor stack?
Which test criteria should Umesh consider to validate the new FileUpload
plugin plays well with the (new and improved) interceptor stack? thanks,
Martin
Date: Sat, 17 Nov 2012 08:51:05 -0800
Subject: Re: processing of multipart request
From: mart...@apache.org
To: dev@struts.apache.org
On Sat, Nov 17, 2012 at 4:14 AM, Fastupload fastupl...@outlook.com
wrote:
Umesh,
thanks for your reply! Based on current file upload framework to
write a
plugin. it only support java.io.File, for example, the Action has to
use
File object to access multipart data of HTTP request. why not we do
access
multipart data directly and efficiently, in stead of temporary file?
so I think we need to refactor current file upload framework in S2 to
support more efficient way. the new file upload framework has the
ability
that enable user config his prefered file upload component and
processing
way.
Great. So do that. Provide a patch that refactors S2, such that the
current
Commons FileUpload code is still the default, and such that an
alternative,
like your fastupload plugin (but not restricted to it), can be configured
by the user if they want it. In your original post, you said you already
have that code, but I could not find it in your svn repo.
Please understand that there is no way that the existing code will be
*replaced* by a new implementation as the default any time soon. There
are
tens of thousands of applications (S1, S2, and many others) that use
Commons FileUpload today, and have done for many, many years, so we know
that code is extremely robust. As far as I can tell, nobody else has ever
heard of fastupload before, and it certainly does not have the kind of
real-world testing that Commons FileUpload has had. If you want to
provide
it as a plugin, people can experiment with it, and deploy it if they
decide
they like it. But we are not going to throw out what has been solid for
years and replace it with something that hasn't been tested like Commons
FileUpload has.
--
Martin Cooper
this is current form of Action access multipart data
public class StrutUploadAction2 extends ActionSupport {
private File photo;
@Override
public String execute() throws Exception {
// …
return super.execute();
}
}
But the efficient way is this or next ..
public class StrutUploadAction1 extends ActionSupport {
private MultiPartFile photo;
private String description;
@Override
public String execute() throws Exception {
// .. ..
return super.execute();
}
}
for more information please look at
https://sourceforge.net/p/fastupload/wiki/Fastupload%20Home/
or
-
public class StrutUploadAction2 extends ActionSupport {
private FileItemStream photo;
@Override
public String execute() throws Exception {
/ /…
return super.execute();
}
}
// in ASF commons fileupload, FileItemStream contains multipart data
in
memory… for more information, please look at
http://commons.apache.org/fileupload/streaming.html
Best Wishes,
Link Qian
On Nov 17, 2012, at 6:18 PM, Umesh Awasthi umeshawas...@gmail.com
wrote:
Link,
I believe that what suggested by others is good way to go,
you can easily create a plugin using fastupload.
one of best feature of S2 is its flexibility to enhance and provide
added
features using plugins.
Thanks
Umesh
On Sat, Nov 17, 2012 at 3:43 PM, Fastupload fastupl...@outlook.com
wrote:
Wes,
I have read struts2 file upload framework and plugin guide about
file
upload. It requires the plugin provides a java.IO.File object to
interceptors. so in the way, upload component has to use temporary
file.
it's not reasonable to better performance.
Here are fast upload API usage and performance
https://sourceforge.net/p/fastupload/wiki/Fastupload%20Home/
https://sourceforge.net/p/fastupload/wiki/Performance%20Comparison/
Link
On Nov 16, 2012, at 6:40 PM, Rene Gielen rgie...@apache.org
wrote:
Going to write a plugin should really be the way to go, as Wes and
Martin already pointed out. There is positive experience with
successful
externally maintained Struts
RE: processing of multipart request
since you DID provide valuable insight on plugin integration... i wanted to
make SURE you were contacted on these particularsforwarding to Link...
thks umesh,
Martin __
Place longwinded disclaimer here
Date: Sun, 18 Nov 2012 00:16:52 +0530
Subject: Re: processing of multipart request
From: umeshawas...@gmail.com
To: dev@struts.apache.org
Martin,
I guess you mentioned me while it should be Link ;-)
Thanks
Umesh
On Sun, Nov 18, 2012 at 12:12 AM, Martin Gainty mgai...@hotmail.com wrote:
for everyone's edification:
what would be the interfaces that Umesh must implement to write a proper
Struts2 plugin?Any changes to the interceptor stack?
Which test criteria should Umesh consider to validate the new FileUpload
plugin plays well with the (new and improved) interceptor stack? thanks,
Martin
Date: Sat, 17 Nov 2012 08:51:05 -0800
Subject: Re: processing of multipart request
From: mart...@apache.org
To: dev@struts.apache.org
On Sat, Nov 17, 2012 at 4:14 AM, Fastupload fastupl...@outlook.com
wrote:
Umesh,
thanks for your reply! Based on current file upload framework to
write a
plugin. it only support java.io.File, for example, the Action has to
use
File object to access multipart data of HTTP request. why not we do
access
multipart data directly and efficiently, in stead of temporary file?
so I think we need to refactor current file upload framework in S2 to
support more efficient way. the new file upload framework has the
ability
that enable user config his prefered file upload component and
processing
way.
Great. So do that. Provide a patch that refactors S2, such that the
current
Commons FileUpload code is still the default, and such that an
alternative,
like your fastupload plugin (but not restricted to it), can be configured
by the user if they want it. In your original post, you said you already
have that code, but I could not find it in your svn repo.
Please understand that there is no way that the existing code will be
*replaced* by a new implementation as the default any time soon. There
are
tens of thousands of applications (S1, S2, and many others) that use
Commons FileUpload today, and have done for many, many years, so we know
that code is extremely robust. As far as I can tell, nobody else has ever
heard of fastupload before, and it certainly does not have the kind of
real-world testing that Commons FileUpload has had. If you want to
provide
it as a plugin, people can experiment with it, and deploy it if they
decide
they like it. But we are not going to throw out what has been solid for
years and replace it with something that hasn't been tested like Commons
FileUpload has.
--
Martin Cooper
this is current form of Action access multipart data
public class StrutUploadAction2 extends ActionSupport {
private File photo;
@Override
public String execute() throws Exception {
// …
return super.execute();
}
}
But the efficient way is this or next ..
public class StrutUploadAction1 extends ActionSupport {
private MultiPartFile photo;
private String description;
@Override
public String execute() throws Exception {
// .. ..
return super.execute();
}
}
for more information please look at
https://sourceforge.net/p/fastupload/wiki/Fastupload%20Home/
or
-
public class StrutUploadAction2 extends ActionSupport {
private FileItemStream photo;
@Override
public String execute() throws Exception {
/ /…
return super.execute();
}
}
// in ASF commons fileupload, FileItemStream contains multipart data
in
memory… for more information, please look at
http://commons.apache.org/fileupload/streaming.html
Best Wishes,
Link Qian
On Nov 17, 2012, at 6:18 PM, Umesh Awasthi umeshawas...@gmail.com
wrote:
Link,
I believe that what suggested by others is good way to go,
you can easily create a plugin using fastupload.
one of best feature of S2 is its flexibility to enhance and provide
added
features using plugins.
Thanks
Umesh
On Sat, Nov 17, 2012 at 3:43 PM, Fastupload fastupl...@outlook.com
wrote:
Wes,
I have read struts2 file upload framework and plugin guide about
file
upload. It requires the plugin provides a java.IO.File object to
interceptors. so in the way, upload component has to use temporary
Re: processing of multipart request
Martin,
Maybe there is a way to support any proposal for file upload component.
Struts2 framework defines an interface , only abstraction actions for access
multipart data, maybe named MultipartData. It should have the key methods,
isFile();
getHeaders();
getInputStream();
getString();
.. etc..
then, the MultiPartRequest interface adds a few methods,
getMultipartData(String ),
getMultipartData s();
for MultiPartRequestWrapper interface adds a few method that read configuration
that can indicates whether new file or old upload framework. the configuration
should be injected into MultiPartRequestWrapper instance at Struts2 bootstrap.
The solution can keep current file upload framework work, as well it has a wild
range extension for upload components. It needn't change interceptors stack.
Fastupload already provide both temporary file and access multipart data
directly way. the second way needs modify struts2 source code. So it's not
public. if you're interest in it. please look at
https://sourceforge.net/p/fastupload/code/ci/718cbd3ff61eb6b088354237ba0f13433d28ef8a/tree/src/main/java/org/apache/struts2/dispatcher/multipart/
thanks,
Link
On Nov 18, 2012, at 6:10 AM, Martin Gainty mgai...@hotmail.com wrote:
since you DID provide valuable insight on plugin integration... i wanted to
make SURE you were contacted on these particularsforwarding to Link...
thks umesh,
Martin __
Place longwinded disclaimer here
Date: Sun, 18 Nov 2012 00:16:52 +0530
Subject: Re: processing of multipart request
From: umeshawas...@gmail.com
To: dev@struts.apache.org
Martin,
I guess you mentioned me while it should be Link ;-)
Thanks
Umesh
On Sun, Nov 18, 2012 at 12:12 AM, Martin Gainty mgai...@hotmail.com wrote:
for everyone's edification:
what would be the interfaces that Umesh must implement to write a proper
Struts2 plugin?Any changes to the interceptor stack?
Which test criteria should Umesh consider to validate the new FileUpload
plugin plays well with the (new and improved) interceptor stack? thanks,
Martin
Date: Sat, 17 Nov 2012 08:51:05 -0800
Subject: Re: processing of multipart request
From: mart...@apache.org
To: dev@struts.apache.org
On Sat, Nov 17, 2012 at 4:14 AM, Fastupload fastupl...@outlook.com
wrote:
Umesh,
thanks for your reply! Based on current file upload framework to
write a
plugin. it only support java.io.File, for example, the Action has to
use
File object to access multipart data of HTTP request. why not we do
access
multipart data directly and efficiently, in stead of temporary file?
so I think we need to refactor current file upload framework in S2 to
support more efficient way. the new file upload framework has the
ability
that enable user config his prefered file upload component and
processing
way.
Great. So do that. Provide a patch that refactors S2, such that the
current
Commons FileUpload code is still the default, and such that an
alternative,
like your fastupload plugin (but not restricted to it), can be configured
by the user if they want it. In your original post, you said you already
have that code, but I could not find it in your svn repo.
Please understand that there is no way that the existing code will be
*replaced* by a new implementation as the default any time soon. There
are
tens of thousands of applications (S1, S2, and many others) that use
Commons FileUpload today, and have done for many, many years, so we know
that code is extremely robust. As far as I can tell, nobody else has ever
heard of fastupload before, and it certainly does not have the kind of
real-world testing that Commons FileUpload has had. If you want to
provide
it as a plugin, people can experiment with it, and deploy it if they
decide
they like it. But we are not going to throw out what has been solid for
years and replace it with something that hasn't been tested like Commons
FileUpload has.
--
Martin Cooper
this is current form of Action access multipart data
public class StrutUploadAction2 extends ActionSupport {
private File photo;
@Override
public String execute() throws Exception {
// …
return super.execute();
}
}
But the efficient way is this or next ..
public class StrutUploadAction1 extends ActionSupport {
private MultiPartFile photo;
private String description;
@Override
public String execute() throws Exception {
// .. ..
return super.execute();
}
}
for more information please look at
https://sourceforge.net/p/fastupload/wiki/Fastupload%20Home/
or
-
public class StrutUploadAction2 extends ActionSupport {
private FileItemStream photo;
@Override
public String execute() throws
