Hi John,
Thanks for finding the cause. I think this is a CDI/Weld issue and
logged a bug against GF/CDI. I can even reproduce using a Servlet.
https://glassfish.dev.java.net/issues/show_bug.cgi?id=13204
Paul.
On Aug 30, 2010, at 9:55 PM, John Lister wrote:
> 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>
> <PGFormTest.zip>