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
>