Thanks, Martin, See within:
<SNIP> On Thu, 24 Feb 2005 20:02:49 -0800, Martin Cooper <[EMAIL PROTECTED]> wrote: > First, let me say that I did not create the current > MultipartRequestHandler interface, and have never liked it, for a > variety of reasons. However, by the time I got involved with it, we > were pretty much stuck with it for backwards compatibility reasons. In > order to retain backwards compatibility in Struts 1.3, we > unfortunately need to continue to live with it. However, that doesn't > preclude the provision of an alternative; it just requires that the > two can coexist. </SNIP> If I am right about the MultipartRequestWrapper and it does not work, we are lucky in that it cannot create backward compatibility issues! ///;-) > > I would say, though, that even though the current interface is rather > less than ideal, the fact that I've personally written three > dramatically different implementations of it (the current Struts > default, one that uses Resin to do the work, and one that uses a > database for file storage) is at least some testament to its > flexibility. My questions have to do more with architectural issues relating to allowing others to do something different. I have no quarrel or special critique with what is or has been done. > > As far as the need for wrapping the request, others have mentioned > this already, but the most basic reason is that, without a wrapper, > calls to request.getParameter() would just plain fail for multipart > requests. Hence any code that accesses parameters would need to be > cognisant of whether the request was multipart or not. That's not > something anyone should have to deal with in their applications, and > it makes sense for a framework to provide this support. I agree. My previous remarks should suffice here. > > What I would like to do is to move the multipart parsing out into a > servlet filter that would sit in front of ActionServlet, passing on a > wrapped request, and unwrapping on the way out. This is much cleaner > than what we have today. This might be cleaner. I don't know for sure about that. But, I am fairly certain that this will exacerbate the sorts of problems I am worried about. This is the approach that Jason Hunter takes and I know it has its merits. But, if we are talking about doing this in a framework that might want to allow alternative and even experimental implementations of file upload applications, I personally think this is a mistake. The reason that we do not use such a > mechanism already is that filters only showed up in Servlets 2.3, and > up to now we have said we were Servlets 2.2 compatible. Also, the > reason the current code is always messing around with wrapping and > unwrapping is that Servlets 2.2 did not permit wrapping a request. > That meant that any time we were passing the request object back to > the container, we needed to unwrap it, while we wanted to pass the > wrapped request to actions, for example, so that calls to > request.getParameter() worked as expected. You can keep 2.3 and 2.2 compatibility by making the parsing and the wrapping take place at the end of the process, which I would very much prefer anyway, for reasons given above. > > Once a filter is in place, it then becomes a question of how the > application obtains any uploaded files. There is also the huge question of how the wrapper and the files are decorated. That is what is critical to my mind. The code I have in the works > as part of Commons FileUpload has methods over and above the standard > request methods that provide access to these through the wrapper. We > can then plug those into FormFile fields in an action form as part of > the population process. We can also look at alternative ways of > providing access to them, if necessary / desirable. Can you make this available for discussion? Or is it available now? Jack -- "You can lead a horse to water but you cannot make it float on its back." ~Dakota Jack~ --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
