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 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* 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/ >>>>> >>>>> >>>>> --------------------------------------------------------------------- >>>>> 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/ > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
