Hi Sergey,
Unless I missed something out, this seems to me like a question you may want to raise at Servlet EG forums. The use of JAX-RS does not seem relevant for the use case you are asking about - or at least I’m not seeing the connection. Perhaps you may want to update the example to demonstrate the JAX-RS related problem that you see?
Cheers,
Marek
> On 14 Apr 2015, at 18:12, Sergey Beryozkin <sberyozkin_at_talend.com> wrote:
>
> Hi Santiago,
>
> thanks for the feedback,
> On 14/04/15 09:42, Santiago Pericas-Geertsen wrote:
>> Hi Sergey,
>>
>>>
>>> POST
>>> a=b&a=c
>>>
>>>
>>> @Produces(MediaType.TEXT_PLAIN)
>>> @Consumes(MediaType.APPLICATION_FORM_URLENCODED)
>>> public String post(@Context HttpServletRequest request) {
>>>
>>> String[] values = request.getParameterValues("a");
>>> }
>>>
>>> should the above code return a "b,c" array ?
>>
>> I think so.
>>
> Right...
>
>>> My answer is JAX-RS does not require it. Can someone clarify please ?
>>
>> You mean because HttpServletRequest is a Servlet type?
>>
>
> Only partially, I thought that this was very specific to Servlet API, the fact that a form payload ends up 'parameterized' in HttpServletRequest.
>
> JAX-RS MessageBodyReader is only used if a method signature contains a parameter representing a message body.
>
> So unless the above code works only if the underlying container does some magic then the JAX-RS runtime needs to do a specific 'if' in its code:
>
> If a resource method has no parameter representing a body but the service class has HttpServletContext injected somewhere (in a field or as a parameter), and Consumes is Form, then ensure a form payload processing code is utilized.
>
> And I wonder, given that JAX-RS supports Form, FormParam, MultipartMap, does it really need to go out of its usual way and support this Servlet API specific (I'd say - legacy) interaction pattern where form parameters are treated as HttpServletRequest parameters...
>
> Does it work with RI :-) ?
>
> Thanks. Sergey
>
>
>> — Santiago