DO NOT REPLY [Bug 17583] - Handling parameters from MultipartRequestWrapper

[bu...@apache.org]

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

chris@swebtec.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Version|1.1 RC1                     |1.1 Final



------- Additional Comments From chris@swebtec.com  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: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org