DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://issues.apache.org/bugzilla/show_bug.cgi?id=38613>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=38613 ------- Additional Comments From [EMAIL PROTECTED] 2006-02-12 07:39 ------- (In reply to comment #11) > I like the idea of turning the multipart handling into a chain. However, I > have some concerns about the implementation. For example, I'm not thrilled > about ActionContextBase having to know about multipart handlers. It doesn't have to - it could just be in the ServletActionContext - or shoved in the request (or wrapped request). Its just being used to pass the handler from the Command that creates it to the following Command(s) that use it. > I'm also concerned about preserving the existing context when the request is > wrapped; Can't think of a reason why, but it sounds like a good plan. Rather than re- intializing the underlying ServletWebContext - it could be left alone and the "wrapped" request stored in the ServletActionContext. > I'm afraid I haven't had enough time to dig into the code yet to see it that > all works properly. Finally, this makes it so easy to customise multipart > handling that I'd much prefer to expose a cleaned up interface rather than > the very clunky one we've been living with since pre-1.0 days. On the plus > side, this has the potential to re-introduce the ability to disable multipart > handling completely, which is something we had in early Struts versions that > got lost somewhere along the way. My motivation is to disentangle the multipart processing from the form population and factor it out of the static RequestUtils method into a set of classes that can be re-used. Once its out of RequestUtils then I think the struts MultipartRequestHandler could be deprecated and a native Commons FileUpload Command implemented - or any other flavour of file upload processing. > Really, multipart support should be moving to a filter now, rather than being > so intertwined with the request processing. IMO there are pros and cons to both approaches and offering both flavours seems like a good choice. If its in the standard chain config, its one less thing for users to have to configure and with a Filter you can only put it before the request processing starts. IMO it makes more sense to only do the multipart processing after the user has been authorized to execute the action. But mainly I think its about user preference - I'm sure there would be die-hard advocates of both :-) > I actually have the implementation for this as part of FileUpload sitting on > my disk, but I wasn't happy enough with it to put it in FileUpload 1.1. Of > course, Struts will still have to recognise the wrapped request, with the > file items in it, but it will certainly reduce the amount of custom code in > Struts. Thanks for the feedback, I'll re-work some of this and post a modified version. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
