On 12/09/12 19:18, Bill Burke wrote:
>
>
> On 9/12/2012 2:08 PM, Santiago Pericas-Geertsen wrote:
>>
>> On Sep 12, 2012, at 11:50 AM, Sergey Beryozkin wrote:
>>
>>> I still haven't got an answer as to why this provider needs 'Type' and
>>> 'Annotation[]' (knowing that we are talking about simple non-message
>>> body parameters). Without these two parameters, the runtime can key
>>> ParamConverters, and it knows Class<?> of such parameters.
>>
>> I think Bill may have pointed this out already. One example for
>> Annotation[] is @Encoded. Isn't whatever built-in provider you have know
>> handle to @Encoded for say @QueryParam? E.g.,
>>
>
> Couldn't you add the Annotation[] array list to the ParamConverter
> method signature? Then you wouldn't need a Provider.
ParamConverter would have to become the 'provider' itself, so as far as
a number of Providers is concerned, no gain will be there by dropping
ParamConverterProvider.
So the only benefit then would be the reduction of API classes by 1.
That is 'measurable' IMHO, the fewer classes, the better, but may not be
that big of a deal. Thinking more about it, ParamConverterProvider can
indeed optimize some things, though I guess it will be the
responsibility of the provider to sort individual converters by types
Anyway, indeed, a lot of time has been spent on this issue :-)
Cheers, Sergey
>
>> @QueryParam("foo") @Encoded Foo f, ...
>>
>> As for generic types, JAX-RS 1.X already supports List<T>, Set<T> and
>> SortedSet<T> for params, and the proposed signature seems consistent
>> with existing ones.
>>
>> Having said I'm not sure about how multi-valued params would be
>> handled by ParamConverter. Consider,
>>
>> @HeaderParam("Link") Set<Link> linkHeaders, ...
>>
>> Should I define a converter for Link (possibly called multiple times)
>> or should I define a converter for Set<Link> (and that leads to other
>> questions)?
>>
>
> A related queston is, should HeaderDelegate be deprecated?
>