You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@struts.apache.org by Filippo Munafò <fm...@kion.it> on 2016/02/23 12:46:56 UTC
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.
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.
The request is: can you change the MultiPartRequestWrapper, and the
JakartaMultiPartRequest, adding a public getFileItems(String) method?
Another question: in Dispatcher.wrapRequest there is no update of request
in context, so a ServletActionContext.getRequest() never return the
MultiPartRequestWrapper (or StrutsRequestWrapper). Why?
Thanks,
Filippo
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
RE: MultiPartRequestWrapper
Posted by Filippo Munafò <fm...@kion.it>.
>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:mgainty@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.Nenning@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-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
RE: MultiPartRequestWrapper
Posted by Martin Gainty <mg...@hotmail.com>.
> To: dev@struts.apache.org
> Subject: Re: MultiPartRequestWrapper
> From: Christoph.Nenning@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 DefaultFileItemFactory located @<BR>http://www.grepcode.com/file_/repo1.maven.org/maven2/commons-fileupload/commons-fileupload/1.3.1/org/apache/commons/fileupload/DefaultFileItemFactory.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.struts2.dispatcher.Dispatcher.cleanupRequest<BR>MG>org.apache.struts2.interceptor.FIleUploadInterceptor.intercept<BR>
If you think it is a bug you can create another jira.
MG>suggest testing getFileItems(String) with FileUploadInterceptorTest.java located at<BR> /Struts/src/plugins/dojo/init/src/core/src/test/java/org/apache/struts2/interceptor/FileUploadInterceptorTest.java<BR>
MG>
/Struts/src/plugins/dojo>mvn test>
> Regards,
> Christoph
>
> This Email was scanned by Sophos Anti Virus
RE: MultiPartRequestWrapper
Posted by Filippo Munafò <fm...@kion.it>.
> 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.Nenning@lex-com.net]
Sent: martedì 1 marzo 2016 13:43
To: Struts Developers List <de...@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.Nenning@lex-com.net]
> Sent: mercoledì 24 febbraio 2016 16:27
> To: Struts Developers List <de...@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-unsubscribe@struts.apache.org For
> additional commands, e-mail: dev-help@struts.apache.org
>
This Email was scanned by Sophos Anti Virus
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
RE: MultiPartRequestWrapper
Posted by Christoph Nenning <Ch...@lex-com.net>.
> > 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.Nenning@lex-com.net]
> Sent: mercoledì 24 febbraio 2016 16:27
> To: Struts Developers List <de...@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-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
This Email was scanned by Sophos Anti Virus
RE: MultiPartRequestWrapper
Posted by Filippo Munafò <fm...@kion.it>.
> 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.Nenning@lex-com.net]
Sent: mercoledì 24 febbraio 2016 16:27
To: Struts Developers List <de...@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-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: MultiPartRequestWrapper
Posted by Christoph Nenning <Ch...@lex-com.net>.
> 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