Using JRuby 1.6.1, JRuby-Rack 1.0.9 and Warbler on Tomcat 6 with RequestDumperValve causes problems

Hi,

Considering the problem in http://jira.codehaus.org/browse/JRUBY-2497 -
what
is the current state of this issue ?
We are having the same problem when using the RequestDumperValve - it
seems
that just because the valve calls request.getParam(), the body of the
request gets corrupted and later, when it arrives at Rails, the request
parameters are corrupted. Actually, the servlet spec says the same -
accessing the request parameters in the one way does not guarantee that
you
can later access them in the other.

Is there any fix for that ? Or the only rescue is to remove the valve,
or
implement your own filter/request wrapper ?

Thanks and Kindest Regards,
Krum.

Is it possible to configure a servlet filter in front of the request
dumper valve? The request needs to be reset after the dumper valve
calls getParameters. I have a “RequestCapture” class in my Refactoring
to Rails project that can be used for this:

The main issue is to wrap the request so that the default
#getParameters method doesn’t get called. Instead, the RequestCapture
class always reads the body from the stream and parses it manually, so
the stream can be “rewound” so Rails will see the body.

I hope to extract this logic into reusable classes into a future
JRuby-Rack release, but have not gotten to it yet.

/Nick

Hi Nick,

Thanks for your reply!
I am not aware whether its possible to put a filter before the valve,
but I
doubt it - since filters are meant to be used per application, and
valves
are centrally configured for the entire Tomcat instance. But it could be
still possible. I think that it’s worth addressing this question to the
Tomcat community.

It’s really great that you have developed this filter, which will
probably
solve the problem for Rails. I will definitely take a look at it.
But don’t you think this issue should be solved on an earlier phase - in
the
very valves ? Since tomorrow some other Tomcat-X adapter will probably
have
the same issue, if the X part relies on accessing the request stream.
IMHO,
it is within the responsibility of the one who reads the stream, to
recover
it for others that are waiting on the chain for it…

Kindest Regards,
Krum.