jsr339-experts@jax-rs-spec.java.net

[jsr339-experts] Re: [jax-rs-spec users] Re: Re: Re: RESTEasy StringConverter

From: Sergey Beryozkin <sberyozkin_at_talend.com>
Date: Tue, 3 Jul 2012 14:39:49 +0100

On 03/07/12 14:36, Bill Burke wrote:
>
>
> On 7/3/12 9:33 AM, Sergey Beryozkin wrote:
>> On 03/07/12 14:27, Bill Burke wrote:
>>>
>>>
>>> On 7/3/12 8:31 AM, Sergey Beryozkin wrote:
>>>> On 03/07/12 13:22, Marek Potociar wrote:
>>>>>
>>>>> On Jul 3, 2012, at 2:08 PM, Sergey Beryozkin wrote:
>>>>>
>>>>>> On 03/07/12 13:04, Marek Potociar wrote:
>>>>>>>
>>>>>>> On Jul 3, 2012, at 11:04 AM, Sergey Beryozkin wrote:
>>>>>>>
>>>>>>>> On 02/07/12 17:57, Marek Potociar wrote:
>>>>>>>>> On Jul 2, 2012, at 5:49 PM, Bill Burke wrote:
>>>>>>>>>
>>>>>>>>>> Sorry, catching up after a mini-vacation with family.
>>>>>>>>>
>>>>>>>>> No problem. Hope you had fun.
>>>>>>>>>
>>>>>>>>>> We have a toString(...) for client side. Use both in our
>>>>>>>>>> low-level, jax-rs-2.0-like client API and also within our proxy
>>>>>>>>>> framework. Would still be useful for JAX-RS 2.0 when passing
>>>>>>>>>> objects to WebTarget.pathParam and Webtarget.queryParam as well
>>>>>>>>>> as when creating forms.
>>>>>>>>>
>>>>>>>>> Ah, seems so obvious now :) Thanks!
>>>>>>>>
>>>>>>>> So why would one prefer implementing StringConverter as opposed to
>>>>>>>> overriding toString() ? I do not understand the case
>>>>>>>
>>>>>>> Perhaps because you can't override toString as the class is out of
>>>>>>> your control (JDK classes, 3rd party modules...)
>>>>>>
>>>>>> Sure - this means we want to introduce a wrapper around such classes.
>>>>>> However why can't this wrapper offer a custom toString() ?
>>>>>
>>>>> I think the converter approach is more consistent with JAX-RS entity
>>>>> providers where serialization is separated from the Java object model.
>>>>
>>>> OK
>>>>
>>>>> Also don't think that wrappers would make the code look cleaner or
>>>>> more readable in general.
>>>>
>>>> ServiceConverter implementations are the wrappers around those classes
>>>> you've referred to earlier.
>>>>
>>>> Anyway, if we have StringConverter introduced and utilized for the
>>>> parameter conversion on the client side then one has to support them
>>>> for
>>>> converting Strings on the server side to custom types representing URI
>>>> or form parameters, in addition to the default fromString()/etc.
>>>>
>>>>
>>>
>>> FWIW, I didn't personally decide to add this feature to Resteasy. It was
>>> proposed by and implemented by a contributor to fit his specific need.
>>> Then a bunch of other users had the need for it as well. The fact that
>>> Jersey has something similar tells you that its a feature developers
>>> need.
>>>
>> I see Jersey and RestEasy references in nearly every post now :-).
>> FYI, in CXF we have something called ParameterHandler for converting
>> String to typed objects, which as a side note, reflects the 'scope'
>> better, IMHO.
>>
>> The goal of the previous message was to suggest that if we have an
>> additional utility for converting Objects to Strings (specifically for
>> supporting the parameter conversion) then there has to be a symmetric
>> support for converting such String back to the custom Objects
>>
>
> Oh, I"m sorry, read too fast. Sorry if I misinterpreted your response. I
> don't like the name ServiceConverter, as this could be used on the
> client side as well. (the back to custom object thang).
>

No problems :-).
Having an additional conversion support will be useful, I agree the
StringConverter idea can help

Cheers, Sergey