Hi Paul, after some code stripping and head scratching, I finally
discovered what causes the anomalous behaviour - The inclusion of CDI in
the webapp (well the inclusion of an "empty" beans.xml file in
/WEB-INF). I'm not sure if this is a Jersey issue or some wierd thing
going on with cdi/weld and glassfish. Either way I can reproduce it and
a simple web-app is attached.
The following demonstrate
curl -d x=b -d param=y
http://localhost:8080/PGFormTest/formTest/
gives : FormData={}
curl -d x=b -d param=y
http://localhost:8080/PGFormTest/paramTest/
gives : Form Param=b
curl -d x=b -d param=y
http://localhost:8080/PGFormTest/bothTest/
gives : FormData={param=[y], x=[b]} & X=b
All three throw the warning about an empty request body.
removing the beans.xml file works as expected and returns:
FormData={param=[y], x=[b]}
I've filled an issue
(
https://jersey.dev.java.net/issues/show_bug.cgi?id=579) with said
attachement as well.
On another note, only using GF 3.1 I also get these errors logged
WARNING: WEB9052: Unable to load class postParam, reason:
java.lang.ClassNotFoundException: postParam
where postParam is a resource method (one for each method in each
resource class)
Thanks
John
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>