You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@struts.apache.org by bu...@apache.org on 2004/05/14 17:11:16 UTC

DO NOT REPLY [Bug 28983] New: - Unimplemented Servlet 2.3 methods in MultipartRequestWrapper

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: dev@struts.apache.org
        ReportedBy: chris@swebtec.com


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: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org