>MG>if you want to get a head start take a look at >MG>DefaultFileItemFactory located >MG>@<BR>http://www.grepcode.com/file_/repo1.maven.org/maven2/commons-fi >MG>leupload/commons-fileupload/1.3.1/org/apache/commons/fileupload/Defa >MG>ultFileItemFactory.java/?v=source
Thanks for your suggest, but there is no reason to create a new FileItem when there is just a FileItem :-) MG>MultiPartRequestWrapper is set in these files: <BR> MG>org.apache.struts2.dispatcher.Dispatcher.wrapRequest<BR>MG>org.apache MG>.struts2.dispatcher.Dispatcher.cleanupRequest<BR>MG>org.apache.struts MG>2.interceptor.FIleUploadInterceptor.intercept<BR> In those files there is no set, just creation or use of MultiPartRequestWrapper. Best regards, Filippo -----Original Message----- From: Martin Gainty [mailto:mgai...@hotmail.com] Sent: giovedì 25 febbraio 2016 02:17 To: dev@struts.apache.org Subject: RE: MultiPartRequestWrapper > To: dev@struts.apache.org > Subject: Re: MultiPartRequestWrapper > From: christoph.nenn...@lex-com.net > Date: Wed, 24 Feb 2016 16:27:11 +0100 > > > Hi, > > we are trying to migrate a big webapp (a thousand pages) from > > struts1 to struts2. > > One of the first step was to introduce the StrutsPreparefilter, > > leaving everything served by the ActionServlet. > > Then we removed the objects request and response from every action's > > methods signature, leaving them managed only in action ancestor class. > > Sounds like an intersting migration strategy. Can you tell us more > about it? > > > Talking about multipart request, we extended JakartaMultiPartRequest > > to override the parse method in order to leave request parsed by our code. > > Now we would like to leave request parse made by > JakartaMultiPartRequest, > > removing the override, but we need access to the fileitems uploaded > > by users. In other words, our action ancestor class needs to get > > access to the "files" properties of JakartaMultiPartRequest through > > the MultiPartRequestWrapper. Otherwise we need to code something > > similar to what is done by the FileUploadInterceptor.intercept and > > create againg > the > > fileitem needed by our application code. > > I would prefer to just use FileUploadInterceptor. > > > The request is: can you change the MultiPartRequestWrapper, and the > > JakartaMultiPartRequest, adding a public getFileItems(String) method? > > Please create jira for that. And specify if you would like to see it > in struts 2.3 series or if you are happy with struts 2.5. > > That method would be trivial to implement for JakartaMultiPartRequest, > but there are other implementations of MultiPartRequest which don't > have easy access to FileItems. So I'm not sure if this will be added. > >MG>if you want to get a head start take a look at >MG>DefaultFileItemFactory located >MG>@<BR>http://www.grepcode.com/file_/repo1.maven.org/maven2/commons-fi >MG>leupload/commons-fileupload/1.3.1/org/apache/commons/fileupload/Defa >MG>ultFileItemFactory.java/?v=source > > > Another question: in Dispatcher.wrapRequest there is no update of > request > > in context, so a ServletActionContext.getRequest() never return the > > MultiPartRequestWrapper (or StrutsRequestWrapper). Why? > > > When you look at FileUploadInterceptor.intercept you see that > MultiPartRequestWrapper is obtained from ActionContext. But I don't > know where it is set. > MG>MultiPartRequestWrapper is set in these files: <BR> MG>org.apache.struts2.dispatcher.Dispatcher.wrapRequest<BR>MG>org.apache MG>.struts2.dispatcher.Dispatcher.cleanupRequest<BR>MG>org.apache.struts MG>2.interceptor.FIleUploadInterceptor.intercept<BR> If you think it is a bug you can create another jira. MG>suggest testing getFileItems(String) with MG>FileUploadInterceptorTest.java located at<BR> MG>/Struts/src/plugins/dojo/init/src/core/src/test/java/org/apache/strut MG>s2/interceptor/FileUploadInterceptorTest.java<BR> MG> /Struts/src/plugins/dojo>mvn test> > Regards, > Christoph > > This Email was scanned by Sophos Anti Virus --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
