On Fri, 25 Feb 2005 04:51:27 -0000, Niall Pemberton <[EMAIL PROTECTED]> wrote: > > ----- Original Message ----- > From: "Martin Cooper" <[EMAIL PROTECTED]> > Sent: Friday, February 25, 2005 4:25 AM > > > On Fri, 25 Feb 2005 04:15:17 -0000, Niall Pemberton > > <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
