Sorry, the user says "I use it for fetching domain objects from a
database using the primary key.", I missed that bit.
Still not seeing how the intermediate provider is helping,
sharing an example would make it much clearer
Cheers, Sergey
On 06/09/12 14:18, Sergey Beryozkin wrote:
> 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
>>
>