Hi Paul, thanks for looking into this, the behaviour is bizarre. I was
just preparing a test case to post demonstrating the problem when I
discovered it worked as expected (as you describe) except my full
application exhibits the problem. More bizarre is that the app only
shows it under Glassfish 3.1 (currently using b17) and works perfectly
under 3.0.1.
I'll strip down my full app to try and get it to the point where it is a
single class that fails or I discover which bit causes the issue and let
you know.
John
ps, using curl or dumping out the packets sent to the server from a
browser show that the request body is indeed filled with the parameters
as expected.
Paul Sandoz wrote:
> <div class="moz-text-flowed" style="font-family: -moz-fixed">
> On Aug 30, 2010, at 11:44 AM, Paul Sandoz wrote:
>
>> Hi John,
>>
>> This behavior is triggered for:
>>
>> 1) POST request with the media type
>> "application/x-www-form-urlencoded" and there are no bytes to read
>> from the request input stream; and
>>
>> 2) there are parameters present, HttpServletRequest.getParameterNames
>> returns a non-empty enumeration.
>>
>> Would it be possible to log the request being received from the
>> server to check what the client is sending?
>>
>> It may be you might be able to reproduce the same behavior using just
>> a raw servlet. If the request input stream is empty and you know it
>> should be there is definitely a regression in the Web container.
>>
>> In the meantime i will check the latest GF nightly to see if there is
>> a regression in the Web container.
>>
>
> I tried with the latest nightly:
>
> b18-08_27_2010
>
> modifying the hello world web app sample adding a POST method:
>
> @POST
> public String post(Form form) {
> return (form == null) ? "null" : form.toString();
> }
>
> with curl:
>
> curl -d a=b -d x=y http://localhost:8080/helloworld-webapp/helloworld
>
> and the output was "{a=[b], x=[y]}". Thus i cannot reproduce.
>
>
> I am thinking that in any case it may be possible to relax the
> restriction on Form/MultivaluedMap<String, String> if we supply a
> server-side specific message body reader that checks for a request
> property that will be present for the case of a filter or valve
> consuming the form parameters. Can you please log an issue?
>
> Paul.
>
>>
>> There are two possible work around:
>>
>> 1) Include one @FormParam and Form as the method parameters;
>>
>> 2) Define a bean, X say, containing the @FormParam annotations and
>> inject the bean doing @InjectParam X as a method parameter.
>>
>> Paul.
>>
>>
>> On Aug 30, 2010, at 8:01 AM, John Lister wrote:
>>
>>>
>>> Hi, I've just started testing Glassfish 3.1 dev code while currently
>>> using 3.0.1 and come across a situation that I could do with some
>>> advice on, I'm currently using Jersey 1.4.0.
>>> For some of my post requests I've got methods along these lines:
>>>
>>> public Response postXXX(Form formData){
>>> ...
>>> }
>>>
>>> where the request accept a large number of variable parameters which
>>> are then checked within the code depending upon their contents which
>>> seems much preferable to many FormParam tagged parameters. However
>>> using Glassfish 3.1 I now get the following warning:
>>>
>>> WARNING: A servlet POST request, to the URI
>>> http://localhost:8080/xxx/, contains form parameters in the request
>>> body but the request body has been consumed by the servlet or a
>>> servlet filter accessing the request parameters. Only resource
>>> methods using @FormParam will work as expected. Resource methods
>>> consuming the request body by other means will not work as expected.
>>>
>>> and indeed my formData parameter is now null, whereas those tagged
>>> with FormParam are filled. However previous versions of Glassfish
>>> behave differently and fill the map.
>>> As far as I can tell nothing else has changed, there are no extra
>>> (default) servlets or filters installed and the only other servlet
>>> is the jersey one. Is this expected and is it possible to revert to
>>> the previous behaviour or are the other methods of accessing the map
>>> of form params in a request? Using
>>> HttpRequestContext.getFormParameters() also returns an empty map.
>>>
>>> How come @FormParam can access the data, but a Form object cannot -
>>> I'm guessing that it is extracted to generate the @FormParam objects..
>>>
>>> Thanks
>>>
>>>
>>> John
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
>>> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
>> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>>
>
> </div>