jsr339-experts@jax-rs-spec.java.net

[jsr339-experts] Re: [jax-rs-spec users] Re: ParamConverter and Collections

From: Sergey Beryozkin <sberyozkin_at_talend.com>
Date: Mon, 25 Aug 2014 18:30:57 +0100

Hi Santiago,
Cool, thanks for the quick clarification

Cheers, Sergey
On 25/08/14 18:25, Santiago Pericas-Geertsen wrote:
> Sergey,
>
> No, this is not defined nor intended to be supported. Section 3.2 in the spec (which I think needs to explain better ParamConverter) restricts T in List<T> to be a certain type (must satisfy steps 3 or 4).
>
> -- Santiago
>
> On Aug 25, 2014, at 1:15 PM, Sergey Beryozkin <sberyozkin_at_talend.com> wrote:
>
>> Hi Marek, Santiago
>>
>> So I've convinced the user that given
>>
>> @GET
>> public Response get(@QueryParam("a") List<MyAClass> a);
>>
>> ParamConverterProvider is only asked to return a
>> converter for MyAClass.
>>
>> The user is very keen to explore the explicit collections root though and now we have the following:
>>
>> @GET
>> public Response get(@FormParam("a") List<List<MyAClass>> a);
>>
>> and expecting ParamConverterProvider.getConverter to return a converter for List<MyAClass>.
>>
>> I do not even know what to do here. My position is that using something like "List<List<MyAClass>>" to represent a single JAX-RS parameter is undefined in the spec. Technically I can imagine that "List<List<MyAClass>>" can be handled, and only by ParamConverterProvider but something like "List<List<MyAClass>>" can not be generalized at the spec API docs level, only List<MyClass> can be, the latter representing a repetitive parameter whose values have to be mapped to MyClass.
>>
>> Can you give me another favor and clarify is it spec compliant to use deeply nested collection parameters (the depth level > 1), i.e, is having something like
>>
>> @GET
>> public Response get(@FormParam("a") List<List<MyAClass>> a);
>>
>> and a registered ParamConverter for List<MyAClass>
>>
>> is expected to work ?
>>
>> Thanks, Sergey
>>
>>
>>
>> On 14/08/14 15:28, Sergey Beryozkin wrote:
>>> Hi Marek
>>> On 14/08/14 14:56, Marek Potociar wrote:
>>>> Hi Sergey,
>>>>
>>>> For QueryParam Jersey automatically creates a List/Set/SortedSet as
>>>> required by #5 in the javadoc. We use the ParamConverter in step #4
>>>> for non-collection types.
>>>>
>>>> HTH,
>>> Sure it does, thanks for the confirmation, and for being very nice too :-)
>>>
>>> Cheers. Sergey
>>>
>>>> Marek
>>>>
>>>> On 13 Aug 2014, at 23:11, Sergey Beryozkin <sberyozkin_at_talend.com> wrote:
>>>>
>>>>> Hi Marek
>>>>>
>>>>> Can you please be very nice tomorrow :-) and reply to the following:
>>>>>
>>>>> A CXF user is wondering if CXF is compliant or not with respect to
>>>>> the way it treats collections and ParamConverters.
>>>>>
>>>>> Consider:
>>>>>
>>>>> @GET
>>>>> public Response get(@QueryParam("a") MyAClass a);
>>>>>
>>>>> ParamConverterProvider.getConverter(MyAClass.class, MyAClass.class,
>>>>> annotations);
>>>>>
>>>>> would return the converter.
>>>>>
>>>>> Now, next we have
>>>>>
>>>>> @GET
>>>>> public Response get(@QueryParam("a") List<MyAClass> a);
>>>>>
>>>>> The user expects that ParamConverterProvider is asked to return a
>>>>> converter for List<MyAClass>.
>>>>>
>>>>> I said no, there was an agreement that the runtime was dealing with
>>>>> managing the actual Lists or Sets, and ParamConverterProvider would
>>>>> only be asked to provide a converter for MyAClass.
>>>>>
>>>>> My other argument was that if the runtime were to ask to provide the
>>>>> list/set converters then, given a query like "?a=2&a=4", the runtime
>>>>> would have to pass the actual "a=2&a=4" String to the converter
>>>>> (possibly re-created by the runtime in case the original query is
>>>>> more involved, with multiple 'a' being mixed with other parameters)
>>>>> for it to parse it in order to convert to List/Set. This appears to
>>>>> be fundamentally wrong to me: this would mean that the same converter
>>>>> would also have to be prepared to parse "a=2;a=4" to support Matrix
>>>>> parameter lists. No idea how would one get the converters to convert
>>>>> a list of headers to List/Set, what the runtime would pass to
>>>>> converter.fromString() in case of multiple headers ?
>>>>>
>>>>> To summarize, I think it is the job of the runtime to take care of
>>>>> managing the actual lists/sets holding multiple parameters.
>>>>>
>>>>> Does it Jersey do it differently ? Bill, what about RestEasy ?
>>>>>
>>>>> Thanks, Sergey
>>>>
>>>
>>
>