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=28983>. 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=28983 Unimplemented Servlet 2.3 methods in MultipartRequestWrapper Summary: Unimplemented Servlet 2.3 methods in MultipartRequestWrapper Product: Struts Version: 1.1 Final Platform: All OS/Version: All Status: NEW Severity: Normal Priority: Other Component: Controller AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] The MultipartRequestWrapper contains 4 methods that are new to Servlet 2.3. However rather than delegate to the original request object, they are not implemented. Unfortunately this problem means that Struts is NOT compliant with Servlet 2.3 or 2.4. When using Struts on a 2.3+ servlet container I have to write code such as: if ("org.apache.struts.upload.MultipartRequestWrapper".equals(request.getClass().getName())) { ... } Note that I can't use instanceof since that would introduce a runtime dependency on Struts to my libraries (which aren't always used from Struts-based applications). The solution is to introduce a *compile time* dependency on Servlet 2.3 to Struts. By changing the 4 additional 2.3 methods to delegate to the real request object, the 2.3 support will work 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 preferable to Struts silently returning null from a method which is spec'ed to always return a valid object. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
