----- Original Message ----- From: "Martin Cooper" <[EMAIL PROTECTED]> Sent: Friday, February 25, 2005 5:22 AM
> 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 > 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
