On Sep 12, 2012, at 1:51 PM, Sergey Beryozkin <sberyozkin_at_talend.com> wrote:
> 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.
No, that's not the case. I don't know where did you get it since entity providers deal only with entity and parameter convertors deal with the injected @*Param types, from which the only @FormParam may be taken from entity. Also, entity providers operate based on media types. parameter convertors operate only based on the Java type. So again, no, it's not the case.
>>
>> 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.
In one of my earlier examples I'm talking about the fact that a single convertor provider may provide various (perhaps generic) convertors properly initialized for a particular type. E.g. you may have a single provider that is able to provide pre-initialized generic converters that use a string constructor or valueOf, fromString/toString methods in the target type. With the converter provider you don't need to compute that information by introspecting the target type at runtime.
>>
>> 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.
Well, I'm sure I have provided quite a lot of support material in this case already to be accused of not being supportive. Whether it does or doesn't meet your personal expectations is a separate, unrelated topic IMO...
Marek
>>
>> 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
>>>>
>>>
>>>
>>
>>
>
>