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
Thanks, Sergey
--
Sergey Beryozkin
Talend Community Coders
http://coders.talend.com/
Blog: http://sberyozkin.blogspot.com