On 21/09/12 15:04, Marek Potociar wrote:
>
> On Sep 18, 2012, at 10:17 PM, Sergey Beryozkin<sberyozkin_at_talend.com> wrote:
>
>> On 18/09/12 15:13, Marek Potociar wrote:
>>> With provider any pre-computations can be done once during deploy-time. With just converter you'd have to do these every single time you need the converter.
>>
>> The more I'm thinking about it the more I'm getting convinced this is not a strong argument, a case for the optimization, to get a new interface introduced at the API level.
>>
>> IMHO it's a typical 80/20 case. In 80% cases (I'd go and say in 90% at least) we have the default algorithm (valueOf, constructors accepting Strings, etc) for mapping Strings to custom types working perfectly OK - I can imagine even this default algo be implemented by a provider but it can be without it.
>>
>> To me having one interface less is a bigger deal than having an optimization working for 20% or even less case.
>
> To me it's opposite.
>
>>
>> By the way, having a single ParamConverter<Object> would probably do the same if it were needed, the optimization...
>
> Not sure I follow.
May be something like this:
public class DefaultParamConverter implements ParamConverter {
Map<Class<?>, ParamConverter> userProviderConverters;
Set<Class<?>> supportedClasses;
public <T> T fromString(String value, Class<T> cls, Type t,
Annotation ann) {
if (supportedClasses.contains(cls)) {
return fromDefaultConverter(value, cls)
} else {
return userProviderConverters.get(cls).fromString(...);
}
}
}
I don't know :-), may be I should not have typed to show my ignorance
:-), but here you go...
Sergey
>
> Marek
>>
>> Sergey
>>
>>
>>>
>>> Marek
>>>
>>> On Sep 18, 2012, at 3:41 AM, Bill Burke<bburke_at_redhat.com> wrote:
>>>
>>>> I still don't get why we need ParamConverterProvider. Just widen fromString and toString
>>>>
>>>> ParamConverter<T> {
>>>>
>>>> fromString(Class type, Type genericType, Annotation[] annotations);
>>>> toString(Object obj, Annotation[] annotations)
>>>> }
>>>>
>>>> Correct me if i'm wrong, but the model with ParamConverterProvider is inefficient as you'd have to loop over every registered converter to until you got one that matched. Instead, you can match the type to the generic parameter passed when implementing the ParamConverter interface. Just like we do with ExceptionMapper.
>>>>
>>>> On 9/6/2012 8:49 AM, Marek Potociar wrote:
>>>>> Please check the user comment in the corresponding issue for the motivation:
>>>>> http://java.net/jira/browse/JAX_RS_SPEC-61
>>>>>
>>>>> 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
>>>>>
>>>>
>>>> --
>>>> Bill Burke
>>>> JBoss, a division of Red Hat
>>>> http://bill.burkecentral.com
>>>
>>
>