On 12/09/12 11:39, Sergey Beryozkin 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...
I mentioned headers too, well, may be forms ? Which ones are you
referring to, in context of this discussion ? Forms may be
I start thinking, are you referring to the parameters representing a
request body too
>>
>> 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.
By the way, missed the above, that confuses me even more. Well, not
quite, but still does. I asked in the previous message, where is the
type info is coming from, in case of the URI.
I can see say a form parameter value being XML, that is fine, and I can
even imagine, this XML may have a type info, is that the kind of the
case you are after ?
Thanks, Sergey
>>
>> 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.
>
> 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.
>
> So it is there and I have to squeeze any meaningful information, why ?
>
> Please show the *example*.
>
> 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
>>>>
>>
>
>