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