> Sounds like an intersting migration strategy. Can you tell us more about it?
Starting from here: https://struts.apache.org/docs/comparing-struts-1-and-2.html we have worked a lot with the first and the third feature, because we think them are the keys for a successful migration. We have also removed any reference to ActionForm because we don't use it, our view is made in xslt. We have also written an xslt to migrate every struts-config.xml to struts.xml: it's almost done, even if at this stage we have only tested it, but we have not released all the struts.xml in production. Think about 3134 ActionMapping in 396 struts-config!!! And there is a lot more.... > I would prefer to just use FileUploadInterceptor. At this moment we don't use Interceptor because we are just using StrutsPrepareFilter, no execute. > 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. We would like to see it in 2.3 series, 2.3.25, because we haven't yet planned un update to the future 2.5.x: https://issues.apache.org/jira/browse/WW-4609 > When you look at FileUploadInterceptor.intercept you see that > MultiPartRequestWrapper is obtained from ActionContext. But I don't know > where it is set. If you think it is a bug you can create another jira. You are right, but I think that the "problem" is the use of StrutsPrepareFilter instead of an execute one, even if I'm not sure. https://issues.apache.org/jira/browse/WW-4610 Thanks, Filippo -----Original Message----- From: Christoph Nenning [mailto:christoph.nenn...@lex-com.net] Sent: mercoledì 24 febbraio 2016 16:27 To: Struts Developers List <dev@struts.apache.org> Subject: Re: MultiPartRequestWrapper > 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. > > 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. If you think it is a bug you can create another jira. 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
