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
>
> I'm interested to see more details
>
> Thanks, Sergey
>
>> Marek
>>
>>>
>>>
>>> --
>>> Bill Burke
>>> JBoss, a division of Red Hat
>>> http://bill.burkecentral.com
>>