By the way, what probably confuses users is that
ParamConverterProvider accept both Class<?> and Type parameters,
I'm presuming it is to support rare cases like MyAClass<E> or
List<MyAClass<E>>.
Thanks, Sergey
On 25/08/14 18:30, Sergey Beryozkin wrote:
> 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
>>>>>
>>>>
>>>
>>
>