On 12/09/12 16:13, Marek Potociar wrote:
>
> 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 know how MBRs work but the way you were answering made me think about it.
>>>
>>> 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.
Right...So then it is all about the optimization. Why you were referring
to that JIRA issue or mentioning JAXB, I do not know.
I still haven't got an answer as to why this provider needs 'Type' and
'Annotation[]' (knowing that we are talking about simple non-message
body parameters). Without these two parameters, the runtime can key
ParamConverters, and it knows Class<?> of such parameters.
These are the details you are not prepared to get into, but I've had enough
>
>>>
>>> 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...
Well, I did not expect you to answer but since you did:
- I'm not accusing
- You do not have to be supportive
- I've been upset with the dismissive answer "just go and check Jersey
sources"
>
> 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
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>