Roel,
On 12/16/15 4:56 AM, Roel Storms wrote:
> 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
2015-12-09 16:35 GMT+03:00 André Warnier (tomcat) :
> On 09.12.2015 14:03, Roel Storms wrote:
>>
>> The real requirement is being able to process the body of a request in a
>> Valve without restricting the servlet to call request.getInputStream,
>> getReader and getStream. I have
2015-12-16 14:11 GMT+01:00 Christopher Schultz :
> Roel,
>
> On 12/16/15 4:56 AM, Roel Storms wrote:
> > It should, if you implement parseParameter and all these other methods
> > before getStream is called, in the wrapper itself. But since you haven't
> >
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
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
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
Roel,
On 12/12/15 11:17 AM, Roel Storms wrote:
> I believe that this is not entirely what I need. As far as I understand the
> code it will detect if getInputStream or getReader has been called by the
> servlet application. Depending on the usingReader boolean that was set as a
> result, it will
Chris,
I believe that this is not entirely what I need. As far as I understand the
code it will detect if getInputStream or getReader has been called by the
servlet application. Depending on the usingReader boolean that was set as a
result, it will either use _inputReaderBuffer or
On 09/12/2015 11:13, Roel Storms wrote:
> Hello,
>
> In Tomcat 4.1 it used to be possible to specify a custom class for the
> Connector: https://tomcat.apache.org/tomcat-4.1-doc/config/coyote.html
>
> In the newest versions it's only possible to provide a custom Protocol.
> However I would like
2015-12-09 14:13 GMT+03:00 Roel Storms :
> Hello,
>
> In Tomcat 4.1 it used to be possible to specify a custom class for the
> Connector: https://tomcat.apache.org/tomcat-4.1-doc/config/coyote.html
>
> In the newest versions it's only possible to provide a custom Protocol.
>
On 09.12.2015 14:03, Roel Storms wrote:
The real requirement is being able to process the body of a request in a
Valve without restricting the servlet to call request.getInputStream,
getReader and getStream. I have tried by wrapping the request but some
behavior can't be masked. It is also much
The real requirement is being able to process the body of a request in a
Valve without restricting the servlet to call request.getInputStream,
getReader and getStream. I have tried by wrapping the request but some
behavior can't be masked. It is also much more simple to implement by just
extending
Hello,
In Tomcat 4.1 it used to be possible to specify a custom class for the
Connector: https://tomcat.apache.org/tomcat-4.1-doc/config/coyote.html
In the newest versions it's only possible to provide a custom Protocol.
However I would like to modify the Request that is created by the
Roel,
On 12/9/15 8:03 AM, Roel Storms wrote:
> The real requirement is being able to process the body of a request in a
> Valve without restricting the servlet to call request.getInputStream,
> getReader and getStream. I have tried by wrapping the request but some
> behavior can't be masked. It
14 matches
Mail list logo