And looking at the data in Request *before* I invoke getParameter*() in
our code, I see that parametersParsed is set to "true".
I'm not sure if I should expect this to "true" at this point (entry to
my first filter) for a GET request with a fairly stock Tomcat 7.0.50/53
configuration. It doesn't seem like it should be...
Tinkering with the internal state of the Request object, to set
parametersParsed to false and/or parameterMap to null in the debugger
doesn't help getParameterMap() succeed, though...
--
Jess Holle
On 4/7/2014 11:52 AM, Jess Holle wrote:
P.S. The only way I currently know to reproduce this issue is with a
full install of our full commercial product plus optional modules --
and then to load large, sensitive customer data into this product and
execute a very specific use case.
How this could possibly be related to Spring or /any /specifics of
this use is a mystery to me.
I understand, however, that the requirements to reproduce this issue
throw at least the initial troubleshooting and debugging squarely into
my lap, which is why I'm asking for pointers, not filing bugs.
A little more version information (in case it is relevant):
* Sprint 3.2.2
* JDK 7u51
--
Jess Holle
On 4/7/2014 10:21 AM, Jess Holle wrote:
We're seeing a bizarre failure of getParameterMap() wherein this
servlet API returns an empty map.
I thought we'd loused this up somehow via our servlet request
filters, but the debugger shows this result on the very first line of
our very first filter -- with the request object being Tomcat's own.
To make matters worse, this is a GET request with a /very /simple URL.
The query string is very simple "?ids=41&jsonSupport=true". The value
of "ids" varies, but it's numeric and the cases I'm looking at are 2
to 4 digits in length. The rest of the request URI is short and all
ASCII, being of the form {webAppName}/xxxx/yy.
This is being reproduced with both 7.0.50 and 7.0.53 -- with mod_jk
1.2.37 and httpd 2.2.26.
As with https://issues.apache.org/bugzilla/show_bug.cgi?id=55695, we
are using Spring MVC -- and getting a similar error message. Given
the point in request handling at which we're getting the erroneous
result, I don't see how this is actually related to Spring MVC, but I
also don't have any idea how one could reproduce the issue without
Spring MVC or our (large proprietary) web application.
Any suggestions for getting to the bottom of this issue would be
greatly appreciated!
--
Jess Holle
