> You want to migrate more than 3000 actions in just one release? Absolutely not, we are not so crazy :-)
> And you want to do that with automatic changes in code? That's something that we do often, also in other projects, but always with intensive tests. > And you don't want to use default classes of struts2 (such as interceptors)? We do want it, it's our goal. We cannot do it now, because we are still using only ActionServlet, but we sure want to do that. > - have both versions of struts in the project We have just both versions of struts in project. > - migrate a bunch of actions manually for each release Yes, of course > - test that few actions extensively Even more if possible, we have a lot of Jmeter and Selenium tests > - some releases later, when all actions are migrated, remove struts1 After some years...it's a long path! Thanks for your suggestions , I'd love to hear more if you have, Filippo -----Original Message----- From: Christoph Nenning [mailto:christoph.nenn...@lex-com.net] Sent: martedì 1 marzo 2016 13:43 To: Struts Developers List <dev@struts.apache.org> Subject: RE: MultiPartRequestWrapper > > 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.... > You want to migragte more than 3000 actions in just one release? And you want to do that with automatic changes in code? And you don't want to use default classes of struts2 (such as interceptors)? That is brave. In our company we migrate usually like this: - have both versions of struts in the project - migrate a bunch of actions manually for each release - test that few actions extensively - some releases later, when all actions are migrated, remove struts1 Regards, Christoph > > 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 > 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
