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=17583>. 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=17583 Handling parameters from MultipartRequestWrapper [EMAIL PROTECTED] changed: What |Removed |Added ---------------------------------------------------------------------------- Version|1.1 RC1 |1.1 Final ------- Additional Comments From [EMAIL PROTECTED] 2004-05-14 09:57 ------- I've just been burnt by a related problem - the wrapper returns null for getRequestURL(). In the past I've also been burnt by the parameter problem that Anton hit. Saying that you won't fix this in Struts 1.x is hardly acceptable given that this problem means that Struts is NOT compliant with Servlet 2.3 or 2.4. I can fully appreciate that Struts should not *require* a 2.3 or higher container, however it should not *lock you in to using 2.2* without resorting to hacky workarounds in code that would not normally, and should not, have any dependency on Struts. Polluting my framework-agnositc code with gems such as: if ("org.apache.struts.upload.MultipartRequestWrapper".equals(request.getClass().getName()) { ... } ...is not my idea of clean code. Note that I can't even use instanceof since that would introduce a runtime dependency on Struts to my libraries. The solution of course is to introduce a *compile time* dependency on Servlet 2.3 to Struts. Compile time only, not runtime. By changing the 4 additional 2.3 methods to delegate to the real request object, obviously the 2.3 support starts working correctly. But what happens to the 2.2 support? Well since the user's code is only using servlet 2.2 methods, none of these four extra methods should ever get called so there isn't an issue. Even if the methods ARE called from within a 2.2 container, the user will get a NoSuchMethodException which should indicate to them that they've attempted something they shouldn't. Note that you'd get the exact same method if you ran a 2.3 webapp that called those methods from within a 2.2 container. I don't see a problem with this, in fact I see it as the correct behaviour. It's certainly better than Struts silently returning null from a method which is spec'ed to always return a valid object! Of course it would be possible to use reflection to determine if Struts was running inside a 2.2 or 2.3+ container and act appropriately, but I don't think that is a very good idea. Better to just delegate regardless, and make a note of the potential NoSuchMethodException in the Javadocs. Chris Miller --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
