On Nov 19, 2008, at 4:15 PM, Davis Ford wrote:
> Paul -- thanks a lot for the quick response. Confirmed that this does
> fix the issue for me. When you have a chance, can you elaborate
> briefly on your statement about Tomcat logging configuration?
> How/where could I configure Tomcat logging to consume the InputStream
> and cause this issue to crop up again?
>
I mean if a Tomcat valve, say a logging valve, calls
request.getParameterMap() then all the bytes from the input stream of
the request entity will be consumed (for the media type application/x-
www-urlencoded), thus there is nothing for Jersey to consume.
Paul.
> Thanks in advance,
> Davis
>
> On Wed, Nov 19, 2008 at 5:36 AM, Paul Sandoz <Paul.Sandoz_at_sun.com>
> wrote:
>> Hi Davis,
>>
>> It is a bug in Tomcat and also Glassfish (i tried with v2 and v3
>> and can
>> reproduce the same behaviour). It is because Jersey obtains the
>> InputStream
>> instance from the HttpServletRequest which is disabling the form
>> parsing of
>> the parameters in the request, even though no bytes have been read
>> from the
>> stream (at the end of the email is a servlet that reproduces the
>> same bug).
>>
>> You can do this instead:
>>
>> @POST
>> @Produces("text/html")
>> @Consumes("application/x-www-form-urlencoded")
>> public String doPost(@FormParam("x") String x, @Context
>> HttpRequestContext
>> request) {
>> Form f = request.getFormParameters();
>> }
>>
>> But take care that there are no valves in Tomcat logging parameters
>> otherwise Tomcat will consume the request and there will be nothing
>> left for
>> Jersey to read.
>>
>> Paul.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>