You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@struts.apache.org by Niall Pemberton <ni...@blueyonder.co.uk> on 2005/02/25 05:15:17 UTC
Servlet 2.3 Multipart Request Handling
AFAIK there were two issues with multipart request handling that needed
Servlet 2.3 to resolve:
1) Forwarding a "wrapped" Request
http://issues.apache.org/bugzilla/show_bug.cgi?id=17583
2) Un-implemented Servlet 2.3 methods
http://issues.apache.org/bugzilla/show_bug.cgi?id=28983
I think we agreed to move to Servlet 2.3 now(?), so all thats needed to
resolve both of these is:
1) Change the MultipartRequestWrapper to extend the
HttpServletRequestWrapper (and remove the un-implemented Servlet 2.3
methods)
2) Remove the "un-wrapping" code from the PerformForward Command (anywhere
else?)
Anyone have any objections/issues to doing this?
Niall
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Servlet 2.3 Multipart Request Handling
Posted by Joe Germuska <Jo...@Germuska.com>.
At 4:51 AM +0000 2/25/05, Niall Pemberton wrote:
>What do you think about factoring
>the multipart handling in a command for backwards compatibility. Also it
would give the users two options - Command or Filter?
I'd say the main argument for using command (and I don't think it's a
decisive argument) is that we can bundle support for it in the
default chain, while with a filter, we'd have to lead people through
one extra configuration step.
At 9:22 PM -0800 2/24/05, Martin Cooper wrote:
> > What do you think about factoring
>> the multipart handling in a command for backwards compatibility. Also it
>> would give the users two options - Command or Filter? As long as both work
>> in the same way, so that when the population mechanism is hit either would
>> work.
>
>How would this work? I can see parsing the input stream in a command,
>but I don't see how we'd then be able to change Chain's mind about
>what request object it hands out, so that it would subsequently hand
>out the wrapped one.
We could add a "setRequest" method to ServletActionContext. It seems
risky when important values are stored in the request, in that if
someone put a completely different request in, instead of a wrapped
one, certain attributes would just disappear. But it might work, if
people were clear that you shouldn't do that!
joe
--
Joe Germuska
Joe@Germuska.com
http://blog.germuska.com
"Narrow minds are weapons made for mass destruction" -The Ex
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Servlet 2.3 Multipart Request Handling
Posted by Niall Pemberton <ni...@blueyonder.co.uk>.
----- Original Message -----
From: "Martin Cooper" <mf...@gmail.com>
Sent: Friday, February 25, 2005 5:22 AM
> On Fri, 25 Feb 2005 04:51:27 -0000, Niall Pemberton
> <ni...@blueyonder.co.uk> wrote:
> >
> > ----- Original Message -----
> > From: "Martin Cooper" <mf...@gmail.com>
> > Sent: Friday, February 25, 2005 4:25 AM
> How would this work? I can see parsing the input stream in a command,
> but I don't see how we'd then be able to change Chain's mind about
> what request object it hands out, so that it would subsequently hand
> out the wrapped one.
Good point, I hadn't thought about that. Either the wrapping part would have
to stay where it is or we would need to replace the request in the context.
It could be replaced by calling the o.a.c.c.w.s.ServeletWebContext's
initialize method again but thats not very neat. Would be better if there
was a mechanism to "wrap" a Request - come to think of it maybe also a
mechanims to wrap a response as well.
To be honest, I'd assumed that since Commons Chain's definition of a Context
is a java.util.Map, I had kind of assumed that the contexts that were being
defined just had convenience methods to retrieve objects from the underlying
Map. Obviously thats not the case and IMO we loose the simplicity/flexiblity
of Chain by defining a custom API to pass around. Really it seems to me were
not passing a Context at all, just one thats mascarading as a Context, but
is really a custom API.
> The FileUpload filter will make the FileItems available via the
> wrapper, but yes, we could still make the FormFile items available
> though the handler. The handler is going to be a bit of a strange
> beast while it still exists, since it will no longer be necessary to
> do the parsing. Perhaps we should think about this from the "if we
> were starting from scratch" point of view, and then work back to how
> we can keep the current handler around. There's also the catch that
> people may have implemented their own handlers (I know I have in the
> past), which may raise some backwards compatibility questions.
That sounds like a good plan. I actually think the "wrapped request" is a
reasonable approach since I believe moving to Servlet 2.3 resolves any
issues with it. In order for Struts to "automatically populate" these
things, then they need to be put somewhere struts knows about - custom
handlers either use the struts mechaism provided or implement their own. The
one issue I can remember with the multipart design was someone raised
something about uploading multiple files with the same name. So maybe
whatever we add to the wrapper to store FormFile objects should be able to
handle that scenario as well.
> If we compile against 2.3, then there will be missing methods when we
> run under 2.4, which I believe is the issue I've seen come up on the
> lists. However, the issue you raise is also valid. I suspect that the
> only way we can resolve both is to use reflection to determine whether
> we're running under 2.3 or 2.4 and dummy up the method or invoke the
> superclass method, respectively. Not pretty. ;-(
I don't understand this - HttpServletRequestWrapper has default
implementations for all the methods - we would just need to override a few
specific ones. As long as method signatures haven't changed then theres no
compile time dependency - it will just pick up the appropriate one from the
servlet jar. Unless my understanding is horribly wrong?
> --
> Martin Cooper
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Servlet 2.3 Multipart Request Handling
Posted by Martin Cooper <mf...@gmail.com>.
On Fri, 25 Feb 2005 04:51:27 -0000, Niall Pemberton
<ni...@blueyonder.co.uk> wrote:
>
> ----- Original Message -----
> From: "Martin Cooper" <mf...@gmail.com>
> Sent: Friday, February 25, 2005 4:25 AM
>
> > On Fri, 25 Feb 2005 04:15:17 -0000, Niall Pemberton
> > <ni...@blueyonder.co.uk> wrote:
> > > AFAIK there were two issues with multipart request handling that needed
> > > Servlet 2.3 to resolve:
> > >
> > > 1) Forwarding a "wrapped" Request
> > > http://issues.apache.org/bugzilla/show_bug.cgi?id=17583
> > >
> > > 2) Un-implemented Servlet 2.3 methods
> > > http://issues.apache.org/bugzilla/show_bug.cgi?id=28983
> > >
> > > I think we agreed to move to Servlet 2.3 now(?), so all thats needed to
> > > resolve both of these is:
> > >
> > > 1) Change the MultipartRequestWrapper to extend the
> > > HttpServletRequestWrapper (and remove the un-implemented Servlet 2.3
> > > methods)
> > > 2) Remove the "un-wrapping" code from the PerformForward Command
> (anywhere
> > > else?)
> > >
> > > Anyone have any objections/issues to doing this?
> >
> > Not really. However, if we end up going with the filter and wrapper
> > I'm working on (slowly!) for Commons FileUpload, we wouldn't
> > necessarily need our own wrapper.
>
> The changes are pretty minor and if your Commons stuff arrives in time, we
> can simply remove the wrapper from Struts.
That's fine. I can't predict when the FileUpload stuff will arrive
anyway, since (a) I still have some work to finish up, and (b) I need
to wait for IO to release a 1.1, since FileUpload 1.1 will depend on
IO 1.1.
> What do you think about factoring
> the multipart handling in a command for backwards compatibility. Also it
> would give the users two options - Command or Filter? As long as both work
> in the same way, so that when the population mechanism is hit either would
> work.
How would this work? I can see parsing the input stream in a command,
but I don't see how we'd then be able to change Chain's mind about
what request object it hands out, so that it would subsequently hand
out the wrapped one.
> Another thought - rather than putting the FormFile fields in the wrapper
> another approach is to put the Multipart handler in the request (I think we
> already do this) and have the populate mechanims retrieve the FormFile
> fields from the handler.
The FileUpload filter will make the FileItems available via the
wrapper, but yes, we could still make the FormFile items available
though the handler. The handler is going to be a bit of a strange
beast while it still exists, since it will no longer be necessary to
do the parsing. Perhaps we should think about this from the "if we
were starting from scratch" point of view, and then work back to how
we can keep the current handler around. There's also the catch that
people may have implemented their own handlers (I know I have in the
past), which may raise some backwards compatibility questions.
> > Also, you might want to add dummy methods for the new ones added in
> > Servlets 2.4, so that we're compatible there too. Not sure if there's
> > a bug in Bugzilla for that, but it's come up on the lists before.
>
> If were inheriting from HttpServletRequestWrapper then anyone running on
> Servlet 2.4 will have "proper" implementations of those methods available?
> Adding 'dummy' implementation methods would just mean that those methods
> wouldn't work for Servlet 2.4 implementations.
If we compile against 2.3, then there will be missing methods when we
run under 2.4, which I believe is the issue I've seen come up on the
lists. However, the issue you raise is also valid. I suspect that the
only way we can resolve both is to use reflection to determine whether
we're running under 2.3 or 2.4 and dummy up the method or invoke the
superclass method, respectively. Not pretty. ;-(
--
Martin Cooper
> > --
> > Martin Cooper
> >
> >
> > > Niall
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Servlet 2.3 Multipart Request Handling
Posted by Niall Pemberton <ni...@blueyonder.co.uk>.
----- Original Message -----
From: "Martin Cooper" <mf...@gmail.com>
Sent: Friday, February 25, 2005 4:25 AM
> On Fri, 25 Feb 2005 04:15:17 -0000, Niall Pemberton
> <ni...@blueyonder.co.uk> wrote:
> > AFAIK there were two issues with multipart request handling that needed
> > Servlet 2.3 to resolve:
> >
> > 1) Forwarding a "wrapped" Request
> > http://issues.apache.org/bugzilla/show_bug.cgi?id=17583
> >
> > 2) Un-implemented Servlet 2.3 methods
> > http://issues.apache.org/bugzilla/show_bug.cgi?id=28983
> >
> > I think we agreed to move to Servlet 2.3 now(?), so all thats needed to
> > resolve both of these is:
> >
> > 1) Change the MultipartRequestWrapper to extend the
> > HttpServletRequestWrapper (and remove the un-implemented Servlet 2.3
> > methods)
> > 2) Remove the "un-wrapping" code from the PerformForward Command
(anywhere
> > else?)
> >
> > Anyone have any objections/issues to doing this?
>
> Not really. However, if we end up going with the filter and wrapper
> I'm working on (slowly!) for Commons FileUpload, we wouldn't
> necessarily need our own wrapper.
The changes are pretty minor and if your Commons stuff arrives in time, we
can simply remove the wrapper from Struts. What do you think about factoring
the multipart handling in a command for backwards compatibility. Also it
would give the users two options - Command or Filter? As long as both work
in the same way, so that when the population mechanism is hit either would
work.
Another thought - rather than putting the FormFile fields in the wrapper
another approach is to put the Multipart handler in the request (I think we
already do this) and have the populate mechanims retrieve the FormFile
fields from the handler.
> Also, you might want to add dummy methods for the new ones added in
> Servlets 2.4, so that we're compatible there too. Not sure if there's
> a bug in Bugzilla for that, but it's come up on the lists before.
If were inheriting from HttpServletRequestWrapper then anyone running on
Servlet 2.4 will have "proper" implementations of those methods available?
Adding 'dummy' implementation methods would just mean that those methods
wouldn't work for Servlet 2.4 implementations.
> --
> Martin Cooper
>
>
> > Niall
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Servlet 2.3 Multipart Request Handling
Posted by Martin Cooper <mf...@gmail.com>.
On Fri, 25 Feb 2005 04:15:17 -0000, Niall Pemberton
<ni...@blueyonder.co.uk> wrote:
> AFAIK there were two issues with multipart request handling that needed
> Servlet 2.3 to resolve:
>
> 1) Forwarding a "wrapped" Request
> http://issues.apache.org/bugzilla/show_bug.cgi?id=17583
>
> 2) Un-implemented Servlet 2.3 methods
> http://issues.apache.org/bugzilla/show_bug.cgi?id=28983
>
> I think we agreed to move to Servlet 2.3 now(?), so all thats needed to
> resolve both of these is:
>
> 1) Change the MultipartRequestWrapper to extend the
> HttpServletRequestWrapper (and remove the un-implemented Servlet 2.3
> methods)
> 2) Remove the "un-wrapping" code from the PerformForward Command (anywhere
> else?)
>
> Anyone have any objections/issues to doing this?
Not really. However, if we end up going with the filter and wrapper
I'm working on (slowly!) for Commons FileUpload, we wouldn't
necessarily need our own wrapper.
Also, you might want to add dummy methods for the new ones added in
Servlets 2.4, so that we're compatible there too. Not sure if there's
a bug in Bugzilla for that, but it's come up on the lists before.
--
Martin Cooper
> Niall
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Servlet 2.3 Multipart Request Handling
Posted by Dakota Jack <da...@gmail.com>.
I may be off base, Niall, but I think the present way of doing
MultipartRequestWrapper won't work. I have addressed this in the
other thread presently being discussed between the three of us, so I
won't repeat it here. Anyway, these two threads seem to overlap in
theory, unless I am just all wet.
Jack
On Fri, 25 Feb 2005 04:15:17 -0000, Niall Pemberton
<ni...@blueyonder.co.uk> wrote:
> AFAIK there were two issues with multipart request handling that needed
> Servlet 2.3 to resolve:
>
> 1) Forwarding a "wrapped" Request
> http://issues.apache.org/bugzilla/show_bug.cgi?id=17583
>
> 2) Un-implemented Servlet 2.3 methods
> http://issues.apache.org/bugzilla/show_bug.cgi?id=28983
>
> I think we agreed to move to Servlet 2.3 now(?), so all thats needed to
> resolve both of these is:
>
> 1) Change the MultipartRequestWrapper to extend the
> HttpServletRequestWrapper (and remove the un-implemented Servlet 2.3
> methods)
> 2) Remove the "un-wrapping" code from the PerformForward Command (anywhere
> else?)
>
> Anyone have any objections/issues to doing this?
>
> Niall
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
--
"You can lead a horse to water but you cannot make it float on its back."
~Dakota Jack~
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org