Bug 40177 - RequestDumperValve causes getCharacterEncoding to be called
RequestDumperValve causes getCharacterEncoding to be called
Status: RESOLVED FIXED
Product: Tomcat 5
Classification: Unclassified
Component: Unknown
5.5.15
PC Windows XP
: P2 enhancement (vote)
: ---
Assigned To: Tomcat Developers Mailing List
http://nicolas-delsaux.is-a-geek.net/...
:
Depends on:
Blocks:
  Show dependency tree
 
Reported: 2006-08-03 10:07 UTC by Nicolas Delsaux
Modified: 2006-12-27 11:43 UTC (History)
0 users



Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Nicolas Delsaux 2006-08-03 10:07:53 UTC
When RequestDumperValve is activated, getParameterNames is called (from http://
www.koders.com/java/
fid998CD923F9D6A959FE5FB7880A26ADB808D36118.aspx?s=requestdumpervalve it is 
called at line 124). Thus, any further call to setCharacterEncoding is useless 
and the whole application must use the RequestDumperValve (which is, 
unfortunatly for any i18n application, ISO-8859-1).
A possible workaround would be to do a deep clone of the request to be used by 
RequestDumperValve. Obviously, it implies a perforrmance leak, but since it is 
a debug valve, it may seem acceptable.
Comment 1 Mark Thomas 2006-08-03 10:57:26 UTC
This is a known, documented 'feature' of the RequestDumperValve.

If you have a patch for consideration, that would be great.
Comment 2 Jess Holle 2006-08-03 14:54:42 UTC
The only workaround I am aware of for this issue is to wait until the *end* of
the request and *then* call getParameter*() APIs and output request parameter
information.  Doing so at any point prior to this can mess up the application by
prematurely consuming the input stream and/or locking the request character
encoding.

I wrote a servlet request filter to do such things, provide JMX access, run
across all servlet engines, etc -- and thus don't use RequestDumperValve any
more.  Further I suggest to all developers I work with to avoid it except for
light troubleshooting as it causes more troubles to shoot :-)
Comment 3 Yoav Shapira 2006-12-26 06:40:21 UTC
I see that the Valve configuration reference already has a strong note to this
effect.  I added the same note to the Valve's JavaDoc header, and to server.xml.
 I've also marked the RequestDumperValve class as deprecated and told people to
use the RequestDumperFilter instead.
Comment 4 Jason Brittain 2006-12-26 18:59:33 UTC
Hi Yoav.

Making the Javadocs more informative is indeed helpful.  But, both Valves
and Filters exist separately because they are useful for different use cases:
Valves are useful when the administrator wants to do something with requests
at the servlet container level, without modifying webapps that may or may not
be owned or written by the administrator.  Filters are useful when you are the
webapp author, or when you're able and willing to modify the webapp, to do
something with requests.  There are valid uses for each, and the administrator
should choose for themselves from the available options.  I have found
RequestDumperValve useful on a number of occasions where I wanted more info
about the requests/responses to web applications I've developed, plus
webapps that I didn't write.  That includes webapps that were localized and
internationalized (in development, not every bug needs to be investigated
in character sets other than ISO8859-1).  The RequestDumperValve has been
around for quite a while now, and I find it quite useful, even if it doesn't
do everything.

Reopening to request the undeprecation of RequestDumperValve.
Comment 5 Yoav Shapira 2006-12-27 04:26:57 UTC
I've reluctantly un-deprecated and amended the change log as you request.

However, I mostly disagree with your statements: I think Valves are largely
out-dated and should be phased out in favor or portable solutions where
possible.  They don't exist separately because they're useful: they exist
separately because of the historical timeline in which they were developed.
Comment 6 Jason Brittain 2006-12-27 11:43:01 UTC
Thanks Yoav.

> I think Valves are largely out-dated and should be phased out in favor
> or portable solutions where possible.

I agree with that, but even if 80% or 90% of Valves are better off as
Filters, some still aren't.  As a developer I have found many cases over the
years where I needed to write code that could not be part of a webapp, or that
had to use Tomcat's code to do something.  Sometimes (rarely, but sometimes)
the code has to run as part of Tomcat, and Valves are better documented at
this point than <Listener>s are.  Since it's not a servlet, nor a Filter, we
know that it's not portable to other servlet containers.  But, if your company
has already decided to use Tomcat, this is okay.  Not much code needs to go
into a Valve, usually.  And while debugging a webapp that is already packaged,
and/or already deployed, being able to just add a line or two to server.xml
to enable, say, RequestDumperValve (which already exists in Tomcat, ready to
run) helps quite a bit because it is a quick way to investigate a bug.  This
allows us to skip compiling a Filter, installing the class file somewhere,
plus we'd have to add both a <filter> block and a <filter-mapping> block to
the webapp's web.xml for it.  This makes the Valve more convenient in some
situations.  I wish Tomcat came with more useful Valve tools like this one,
not less.

I realize that Valves existed first, and that Filters followed.  Tomcat could
completely drop support for Valves and stay servlet compliant, however it
would take away a useful, helpful feature of Tomcat that people do use at
times.

Thanks again.  :)