users@jax-rs-spec.java.net

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

From: Marek Potociar <marek.potociar_at_oracle.com>
Date: Wed, 4 Jul 2012 11:46:55 +0200

On Jul 3, 2012, at 3:33 PM, 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 :-).

Given my and Bill's backgrounds it's kind of natural, isn't it. I would certainly not object if you referenced your CXF experiences in your posts.

> FYI, in CXF we have something called ParameterHandler for converting String to typed objects, which as a side note, reflects the 'scope' better, IMHO.

I don't think we have already decided on the name.

>
> 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

That's what the issue is about, right? The RESTEasy StringConverter referenced by the issue is a bi-directional convertor. It's also the reason why this email thread started - I wanted to clarify the use cases for one of the conversion directions (object -> string).

Marek

>
> Thanks, Sergey
>
> --
> Sergey Beryozkin
>
> Talend Community Coders
> http://coders.talend.com/
>
> Blog: http://sberyozkin.blogspot.com