On 06/09/12 13:49, Marek Potociar wrote:
> Please check the user comment in the corresponding issue for the motivation:
> http://java.net/jira/browse/JAX_RS_SPEC-61
>
OK. The only question is then is whether we should introduce an
indirection via the provider or have the extra parameters passed to
ParamConverter, after a converter for a given class has been found ?
May be it is OK, the way it is done now. The concern is that in order to
address (IMHO) a very edge case (I've never had a single request for
supporting subclasses during the custom parameter conversion, as opposed
to the cases where we have XML payloads to be be bound to JAXB-managed
classes) we have this indirection.
I can not imagine the practical case. The user comment has a question
mark: "Let's say you have an (abstract?) superclass with subclasses."
It does not seem to work on the server side, given that no extra type
info (like xsi:type in the XML payload) can be found in URI or header
parameters
Thanks, Sergey
> Marek
>
> On Sep 4, 2012, at 6:38 PM, Sergey Beryozkin <sberyozkin_at_talend.com
> <mailto:sberyozkin_at_talend.com>> wrote:
>
>> Hi
>>
>> We have ParamConverterProvider and ParamConverter, I wonder do we
>> really need the former ?
>>
>> Example, individual ExceptionMapper implementations can be registered
>> as providers, why should ParamConverter implementations be created
>> indirectly via ParamConverterProvider ?
>>
>> I can see ParamConverterProvider allows to find the providers for
>> arguments like "List<Book>" - but do we really need it ?
>>
>> Sergey
>