It should, if you implement parseParameter and all these other methods before getStream is called, in the wrapper itself. But since you haven't implemented HttpServletRequest.getParameter* in you example Filter, you will end up using Request.getParameter* which will not use the HttpServletRequest.getStream since it has no knowledge of this wrapper. The wrapped object never uses the wrapped implementation of methods since it has no knowledge of the wrapping.
2015-12-16 4:06 GMT+01:00 Christopher Schultz <ch...@christopherschultz.net> : > Roel, > > On 12/15/15 5:13 PM, Roel Storms wrote: > > I don't believe that your suggestion works, but correct me if I'm wrong. > > You aren't overwriting the getInputStream or getReader method. You are > > wrapping them, which is a big difference. Since the internal > > Request#parseParameter() won't use your wrapped version of the method but > > rather uses it's own version which won't work since you've already called > > getInputStream or getReader. > > My code is a Filter which executes too late. If you implement this as a > Valve, you ought to be able to capture the input data (whether it is a > stream or a reader) and re-play it to any code later in the valve > pipeline. I must admit I haven't read all the Connector/Request code so > I don't know for sure if a Valve wrapping the (non-spec-defined) request > object will be sufficient. > > > In your case it works since you aren't calling getParameter(). You're > > implementation works as long as you restrict your application to using > > getReader or getInputStream. Again, correct me if I'm wrong. Calling > > HttpRequestRecorderWrapper.getParameter() in the web application, should > > mess up your wrapper since it doesn't intercepts this method call and > will > > invoke the Request.getParameter() which will call Request.getStream() and > > not HttpRequestRecorderWrapper.getStream() as you're implementation > > requires. > > Servlet code calling HttpServletRequest.getParameter* should end up > calling getInputStream on the wrapper. If that's not what Tomcat does, > I'd consider it a bug because Filters are supposed to be able to replace > request entities and things like that. > > -chris > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
