On 12/09/12 12:49, Sergey Beryozkin wrote:
> On 12/09/12 12:24, Sergey Beryozkin wrote:
>> On 12/09/12 12:20, Marek Potociar wrote:
>>>
>>> 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.
>>>
>>
>> This is the experts group.
>> I've been patiently asking for the information which justifies the
>> introduction of this provider,
>>
>> Please provide the example, alternatively lets offer a vote
>>
>
> Marek, let me try it differently. From the info you provided I'm
> starting to think that may be you even consider using converters in
> addition to / as replacement to MBR.
>
> I can imagine something like this even
>
> /bar?param=encodedXML
>
> so yes I can see why 'encodedXML' may have to be converted to POJO with
> the help of JAXB.
>
> However, as I said, the extra type info which ParamConverterProvider
> accepts does only make sense (at least as I see it) if we have a task of
> introducing a support for subtypes, etc, and for that to work, the
> encodedXML parameter (as above) has to provide the additional type info
> (xsi:type). In other cases the class of a given parameter is already
> known and it is all a typed ParamConverter alone needs.
>
> Do you see at all what I'm saying above ? Let me know, with one example
> (code) where this extra type info that ParamConverterProvider supports
> actually helps during the conversion.
>
> Also, IMHO, trying to focus on certain minor (the way you see it) issues
> is wrong.
Sorry, meant to say "is not wrong", it is part of the process
> All has to be crystal clear, simplified, whenever possible.
> Thus I expect your support as opposed to the irritation.
>
> Thanks, Sergey
>
>
>> Thanks, Sergey
>>
>>> 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
>>>
>>
>>
>
>