On Sep 12, 2012, at 12:39 PM, Sergey Beryozkin <sberyozkin_at_talend.com> wrote:
> On 12/09/12 11:31, Marek Potociar wrote:
>>
>> On Sep 12, 2012, at 12:15 PM, Sergey Beryozkin<sberyozkin_at_talend.com> wrote:
>>
>>> On 12/09/12 11:11, Marek Potociar wrote:
>>>>
>>>> On Sep 10, 2012, at 11:35 PM, Bill Burke<bburke_at_redhat.com> wrote:
>>>>
>>>>>
>>>>>
>>>>> On 9/10/2012 5:33 PM, Sergey Beryozkin wrote:
>>>>>> On 10/09/12 20:36, Marek Potociar wrote:
>>>>>>> Hello experts,
>>>>>>>
>>>>>>> While we're still working out the updated JAX-RS 2.0 release schedule
>>>>>>> dates, we've been approved to postpone the PR date by at least another
>>>>>>> week. This should help us resolve more issues, including the
>>>>>>> WebTarget/UriBuilder API changes at a more convenient pace as was
>>>>>>> earlier requested by some of you.
>>>>>>>
>>>>>> I'm also interested in getting more feedback on having
>>>>>> ParamConverterProvider - if there's some chance to drop it then it can
>>>>>> be the best time to do it, unless the compelling reason is there to keep
>>>>>> it. Likewise, hoping to get some improvements done to Container filters API
>>>>>>
>>>>>
>>>>> I read the JIRA comment by the user, but I still do not understand why you need ParamConverterProvider.
>>>>
>>>> It's the same concept as with dynamic features. It lets you use the deploy-time information to fine-tune the returned ParamConverter instance for the case. E.g. in Jersey in case of JAXB converters we use the type and annotation information to return a proper converter producing the proper JAXB types.
>>>>
>>>
>>> Converting URI path or query values to JAXB types ? I'm getting lost. Param converter is for converting the individual URI bits or say header values. Do we really have a case for converting that to JAXB ?
>>
>> In Jersey, we do. Also, there are other types of params than just path and query...
>>
>> Anyway, even with just path and query params and a way of converting these from/to a particular Java type using the spec-defined mechanisms (string constructor, valueOf, ...). It's much more performant to inspect the conversion type once at deploy time and craft the generic conversion provider so that at runtime it does the right thing without a need to inspect the type again. Similarly, for a custom type converters - users may want to use e.g. different converter instance based on annotations or actual (sub-)type to be produced/consumed.
>>
>> Bottom line: this is another case when there is information available at the deploy time that could be used to pre-compute or customize certain aspects of runtime and thus avoid the need to to the computations over and over again at runtime. The decoupling interface to convertor provider and convertor enables that approach.
>>
>> Let's move on.
>
> Marek, the information above is useful but is not sufficient. To be honest, I'm not happy at all with the way the conversation is going.
Frankly, me neither. I feel we're spending too much time on going in circles while discussing a minor aspect of the API that
a) is practically proven to work well
b) users want
And despite the examples I have provided, you just keep asking for more, because, for a reason that I fail to understand, the examples and explanations I have provided on top of the example provided by the user in the issue are dismissed by some general comment of yours such as "it's useful but not sufficient". I find it both frustrating and aggravating.
> You've added what I see an extra provider. My motivation is to try and see whenever possible if we can minimize something, remove something, given that the more complex API is, the less successful it is going to become.
My motivation is to keep the API compact too. But it's not my ultimate goal. If I see the practical benefit of the extra class, I'm going to fight for it. And this time I really do.
>
> So it is there and I have to squeeze any meaningful information, why ?
>
> Please show the *example*.
I did and I think I'm done here. If you want more, look at e.g. how StringReader/StringReaderProvider is used in Jersey 1.x.
Regards,
Marek
>
> Thanks, Sergey
>
>>
>> Marek
>>
>>>
>>> I'm interested to see more details
>>
>>>
>>> Thanks, Sergey
>>>
>>>> Marek
>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Bill Burke
>>>>> JBoss, a division of Red Hat
>>>>> http://bill.burkecentral.com
>>>>
>>
>
>
> --
> Sergey Beryozkin
>
> Talend Community Coders
> http://coders.talend.com/
>
> Blog: http://sberyozkin.blogspot.com