On Jan 20, 2009, at 11:14 PM, Samuel Le Berrigaud wrote:
> Hi Paul,
>
> a fix for the 1.0.2 release would be great. I have created the issue
> at: https://jersey.dev.java.net/issues/show_bug.cgi?id=188 and am
> happy to verify when fixed.
>
Thanks!
Paul.
> SaM
>
> On Tue, Jan 20, 2009 at 8:50 PM, Paul Sandoz <Paul.Sandoz_at_sun.com>
> wrote:
>>
>> On Jan 20, 2009, at 1:29 AM, Samuel Le Berrigaud wrote:
>>
>>> Hi Paul,
>>>
>>> after having thought a bit more about the issue I couldn't figure
>>> out
>>> a solution that would comply with the Servlet Spec. and wouldn't
>>> require an additional servlet Filter at the very top of the chain to
>>> wrap the request in some way.
>>>
>>> Your solution would definitely work around the issue. This is
>>> probably
>>> not ideal but I don't see any better solution right now and it seems
>>> pretty reasonable. Would you implement that as Jersey request
>>> filter?
>>> When could it be planned? How could I possibly help?
>>>
>>
>> I will attempt to fix it for the 1.0.2 release, which will happen
>> in about 2
>> to 3 weeks, so it should be in the 1.0.2-SNAPSHOT earlier than
>> that. Can you
>> log an issue and after i fix it verify?
>>
>> I think it best to try and support this without any requirement on
>> the
>> developer to configure anything, it could be implemented as a
>> Jersey filter
>> which is added by the Jersey servlet as you indicate. As you say we
>> can log
>> a warning when the Jersey servlet detects such a case to indicate
>> that only
>> @FormParam can be used under such conditions.
>>
>> Paul.
>>
>>> I think at the very least Jersey should issue a warning when
>>> processing a POST request with url encoded content type and an empty
>>> request input stream. This could be a quick thing to implement if
>>> getting a proper solution in place would take more time.
>>>
>>> SaM
>>>
>>> On Mon, Jan 19, 2009 at 10:02 PM, Paul Sandoz
>>> <Paul.Sandoz_at_sun.com> wrote:
>>>>
>>>> Hi Samuel,
>>>>
>>>> You have correctly diagnosed the issue and i have been discussing
>>>> the
>>>> same
>>>> issue here:
>>>>
>>>>
>>>> http://markmail.org/search/?q=list%3Anet.java.dev.jersey.users#query
>>>> :list%3Anet.java.dev.jersey.users+page:1+mid:ycsknkgspo7svvv2+state:results
>>>>
>>>>
>>>> I would really like to come up with a solution that could work
>>>> under some
>>>> circumstances at least, namely when JAX-RS applications use
>>>> @Form. As i
>>>> said
>>>> in the email thread linked to above there are certain cases that
>>>> are not
>>>> possible to support because the request entity cannot be
>>>> reproduced.
>>>>
>>>> It seems a solution as follows might be acceptable:
>>>>
>>>> 1) The servlet layer checks the form media type;
>>>> 2) If 1) is true then it checks oif the request entity is empty (or
>>>> consumed);
>>>> 3) if 2) is true then it gets the servlet request parameters and
>>>> subtracts
>>>> any parameters declared in the query string using Jersey query
>>>> parsing.
>>>> 4) The remaining parameters are added to a Form instance which is
>>>> added as a special property of the HTTP request.
>>>> 5) When form parameters are processed the special request
>>>> property is
>>>> first
>>>> checked to see if a value is present, of so the Form instance
>>>> that is
>>>> the value
>>>> is used.
>>>>
>>>> Does that sound like a reasonable solution?
>>>>
>>>> Note that i do think that Servlet is broken in this respect. It
>>>> makes it
>>>> impossible to correctly layer on top of servlet, or layer
>>>> filters. So we
>>>> have to work around it.
>>>>
>>>> Paul.
>>>>
>>>>
>>>> On Jan 19, 2009, at 2:12 AM, Samuel Le Berrigaud wrote:
>>>>
>>>>> Hi all,
>>>>>
>>>>> we are experiencing an interesting issue and I hoped that someone
>>>>> would have had a similar problem and could help. Here it is.
>>>>>
>>>>> We deployed a Jersey servlet
>>>>> (com.sun.jersey.spi.container.servlet.ServletContainer) into our
>>>>> application. We have a service that makes use for @FormParam.
>>>>> So when using the Jersey client we do something like:
>>>>>
>>>>> final Form formData = new Form();
>>>>> formData.add("param1", "value1");
>>>>> final MyResource resource =
>>>>>
>>>>>
>>>>> Client.create().resource("http://localhost:8080/
>>>>> rest").path("myresource").post(MyResource.class,
>>>>> formData);
>>>>>
>>>>> on the server side we try to get the value of the param1 like so:
>>>>> @FormParam("param1") String param1
>>>>>
>>>>> Nothing complicated here. However on the server side param1 is
>>>>> always
>>>>> when we use that code. Here is the reason why.
>>>>>
>>>>> The Jersey client generated request has its content type set to
>>>>> "application/x-www-form-urlencoded" which is the correct content
>>>>> type
>>>>> for HTTP POSTs that have a body of url encoded params. However
>>>>> in our
>>>>> application we have several filters, some of which access the
>>>>> request
>>>>> parameters through one of the ServletRequest#getParameter*
>>>>> methods.
>>>>> This means that the application server (I tested on Tomcat 5.5 and
>>>>> Jetty 6.1) will consume the request input stream to access the
>>>>> parameters and leave it empty.
>>>>> So when Jersey tries to parse the request body it finds it to be
>>>>> empty. Hence our param1 being null.
>>>>>
>>>>> I understand that Jersey needs to access the request body to parse
>>>>> those parameters as JAX-RS differentiates FormParameters from
>>>>> Query
>>>>> Parameters, where the Servlet Spec doesn't. But is seems to me
>>>>> that it
>>>>> makes JAX-RS and the Servlet Spec incompatible. Or am I missing
>>>>> something that would make both work happily together?
>>>>>
>>>>> Thanks,
>>>>> Samuel Le Berrigaud.
>>>
>>> ---------------------------------------------------------------------
>>> 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
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>