On Fri, 25 Feb 2005 01:10:45 -0800, Dakota Jack <[EMAIL PROTECTED]> wrote: > 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! > ///;-)
You are _not_ right. It does work, and it has worked for years. I have several production applications that use it, and use custom versions of it, and they work just fine. If you don't believe it works, then try the upload example application. That works too, and I test it before every release and test build goes out the door. It's possible that upload is broken in the latest SVN trunk, since we're in more than a little flux right now, but in 1.2.6 and earlier, it works fine. > > 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. Given that you could (a) choose to not use the filter, simply by not adding it to your web.xml, and (b) you can provide a custom implementation of FileUpload for the filter to use, I don't see how that is constraining. Remember, this point is about the filter only, not the way the uploaded request is made available to the application. > 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. The end of what process? The point is that you cannot pass a wrapped request to the container in Servlets 2.2. When we pass a request to an action, it needs to be wrapped so that calls to request.getParameter() work (and they do work - there's clearly some problem with your testing), and when the action asks us to forward or include or whatever, we need to unwrap before passing it to the container. I don't see how leaving it to "the end of the process" is going to change any of that. In any case, we have decided that we no longer want to be Servlets 2.2 compliant in Struts 1.3 and beyond, so it doesn't really matter. We can wrap and forget it. -- Martin Cooper > > > > 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]
