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.
This is a known, documented 'feature' of the RequestDumperValve. If you have a patch for consideration, that would be great.
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 :-)
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.
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.
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.
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. :)