Thanks, Martin, I know that the upload application works for people that use the default implementation of multipart requests in Struts. I am not talking about that. I am not entirely clear and come to some clarity in stages, just like you do and just like all of us do. Please see within. I think I have some things to say that are helpful. I have decided to start a different thread to state what I would like from Struts v1.3 and beyond.
<SNIP> On Fri, 25 Feb 2005 10:22:54 -0800, Martin Cooper <[EMAIL PROTECTED]> wrote: > On Fri, 25 Feb 2005 01:10:45 -0800, Dakota Jack <[EMAIL PROTECTED]> wrote: > > Thanks, Martin, > > 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. </SNIP> You may not have had a chance to see the discussion between Niall and I. The wrapper works and it does not work. It works for people who use the upload application, but does not work for people who don't, because the proper state is not set until RequestUtils' poplulate method. What appears to be setting the state of the wrapper in the request processor does not work in v1.2.6 or ealier versions. That is to say that if you grab the MultipartRequestWrapper outside of the ActionForm or use the wrapper which exists after line 677 of the RequestProcessor in v1.2.6, while there is code there that looks like it will return parameters, it won't because the state is not set prior to the parsing of the multipart request which does not take place until ll. 609 ff in RequestUtils of v1.2.6. The actual parameters in MultipartRequestWrapper are set in CommonsMultipartRequestHandler in addTextParameter, ll. 404 ff. in v1.2.6. This is not unimportant. By adding state to MultipartRequestWrapper at this stage, it means that there is a MultipartRequestWrapper passed to the application through the Action which has no state and does not work, if you don't use ActionForm. This is not necessary and I think you will agree not desireable. This is not, to my mind anyway, "work[ing] fine". It is not the end of the world, either. But, I would expect you would like to fix that so that is not the result. For lots of reasons developers decide not to use ActionForm and this is especially so with multipart requests because there are lots of implementations out there that do their own thing. They will expect, or at least I did, that the wrapper would work. As it turns out, I had difficulties early on, did not investigate them closely because I just did my own thing and parsed the request independently. Let me put it another way, there is absolutely no need to have the request wrapped in v1.2.6 prior to the RequestUtils and this merely results in having to repeatedly unwrap an object that has no state in the wrapper anyway. We will, I think, and certaily I hope, agree on all of this. <SNIP> > > 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. </SNIP> I want to repeat what I have said previously in this thread. I can get along with whatever you do. So, I am not "constrained" at all in that sense. I have a happily working, buzzing along upload application, which sidesteps any and all difficulties my use of Struts causes and enjoys any and most of the benefits my use of Struts provides. I am not complaining. I am trying to be helpful. More on this below. <SNIP> > 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. </SNIP> The "irony" is that you do this already. There is no need to unwrap the request even in v1.2.6 if you just did not wrap it so early, and, *this is what is important*, the wrapping is a "joke" anyway because nothing is really done in the wrapping, so you can wait until RequestUtils with no consequences except getting rid of the need to wrap it repeatedly. This would work for both v2.2 and v2.3 of the Servlet API. We will agree on this too, I will bet. When I say the MultipartRequestWrapper does not work, I mean that the one passed to the Action does not work unless you implement the ActionForm. This is because the wrapper is not provided with state until RequestUtils populates the ActionForm and, so, if you don't use the form, you get a "sterile" wrapper. <SNIP> > don't see how leaving it to "the end of the process" is going to > change any of that. </SNIP> I expect you now see this? <SNIP> > 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. </SNIP> Okay. Just saying that it is not necessary to do this. I am going to set down a wish list for an upload application in a separate thread, which I hope will be helpful for more than upload applications. 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]
