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
>>
>