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

[jsr339-experts] Re: [jax-rs-spec users] Re: Re: Re: Making Request/Response + builders generic?

From: Sergey Beryozkin <sberyozkin_at_talend.com>
Date: Mon, 24 Oct 2011 21:53:56 +0100

See comments inline

On 24/10/11 19:22, Santiago Pericas-Geertsen wrote:
>
> On Oct 24, 2011, at 10:26 AM, Sergey Beryozkin wrote:
>
>>> Could you elaborate this more? I think you may be on to something here. Are you saying that by making Response generic we are encouraging developers to return collections?
>>o
>> Yes to some extent. One of the patterns which I'm personally observing is that users would like to take on the existing code which can be heavily generilized and turn it as is into the RESTful service, without attempting to change anything.
>> I think it's a valid case but such a code has more chances to survive the changes if beans are involved. This is somewhat off topic, but either way, complicating signatures involving Response to let users type List<Bar> seems unwarranted - we have GenericEntity for users who who'd like to keep returning List<Bar>.
>
> I understand your point now.
>
>>> As for List<Bean>, doesn't JAXB define a bean to XSD mapping? (Apologies if I missed your point completely :)
>>>
>>
>> Sorry, I'm showing my JAXB ignorance here :-). Given two methods, one returning Response<List<Bean>> and the other Response<List<Bean>>
>
> You mean Response and Response<List<Bean>>? Both types are the same in your hypothesis.

was a typo, meant Response<List<Bean>> and say Response<List<Bar>> -
where is the schema describing both return types

>
>> , how can a user document to the consumers the schema of elements returned by both methods ? I guess who type List<Bean> won't care much, so I as said, supporting Response<List<String>> makes it even easier for users not to be concerned
>
> The person that made the suggestion has a lot of experience writing tools. Maybe I'm repeating myself, but his point was simply that using Response<T> simply provides more static information that a tool can use to build a service description of some kind (in HTML or WADL or similar).
>
Well, that is quite important, but I don't see what a tool can do with
Response<List<Bean>> or Response<Set<X>>.

> This also holds for the case in which T is _not_ a generic type. I.e., even if the method returns Response<Bean>. Services supporting hypermedia would return Response<Bean> instead of Bean if using link headers.
>
Response<Bean> is more interesting. I don't know - there has to be some
kind of compromise there.

The question is, who is the receiver of Response<T>. It does not give a
user writing a server code anything, it does not.

So. All the users writing Response in their signature will need to deal
with the rigidness of generics. Some users have the code returning Bean,
others SuperBean, they ll have to start typing those generics in - even
though it does not help them in creating a RESTful service. They will
lose the 'protection' of non-generic Response.

What the tool can do with '? extends Bar' ?.

As far as the tooling is concerned. In CXF we addressed this issue by
adding a dedicated annotation. For example, facilitating the
auto-generation of WADL and helping users produce a robust server side
code are two orthogonal issues.

Now we also have TypeLiteral on the client side.

Thus, again, the questions are:

- who is the ultimate 'receiver' of this extension ?
- what happens on the client side when this extension is added
- Is it all to make the auto-generation of WADL simpler ? If yes - can
we think of other approaches ?

Thanks Sergey


> -- Santiago
>
>>>> On 19/10/11 14:34, Santiago Pericas-Geertsen wrote:
>>>>>
>>>>> On Oct 19, 2011, at 7:41 AM, Sergey Beryozkin wrote:
>>>>>
>>>>>> Thanks, so I'm wondering why would we want to make an effort and let users write
>>>>>>
>>>>>> 'public Response<List<Bean>>'
>>>>>
>>>>> I think it's mostly for readability and tooling. Any form of static tooling would benefit from the extra type information; and it's arguably more readable for developers as well.
>>>>>
>>>>> We sort of went in this direction with WriteToHandlerContext<T> and ReadFromHandlerContext<T>.
>>>>>
>>>>> -- Santiago
>>>>>
>>>>> PS: I think the first example in JAX_RS_SPEC-108 has a typo, and should return Response.
>>>>>
>>>>>> What is a List<Bean> on the wire ? It can not be properly described.
>>>>>> That of course can work, we can even customize easily the wrapper name, etc, but I'm not sure it's a spec level issue at all
>>>>>>
>>>>>> Cheers, Sergey
>>>>>>
>>>>>> On 19/10/11 12:29, Marek Potociar wrote:
>>>>>>> See here for more explanation: http://java.net/jira/browse/JAX_RS_SPEC-108
>>>>>>>
>>>>>>> Marek
>>>>>>>
>>>>>>> On 10/16/2011 06:09 PM, Sergey Beryozkin wrote:
>>>>>>>> Hi
>>>>>>>>
>>>>>>>> On 14/10/11 17:20, Marek Potociar wrote:
>>>>>>>>> Hello experts,
>>>>>>>>>
>>>>>>>>> we've privately received some suggestions to make Req/Resp + builders generic.
>>>>>>>>>
>>>>>>>>> + The advantage would be the type safety as well as potential to preserve type information so that GenericEntity does
>>>>>>>>> not have to be utilized directly (e.g. HTTP resource methods that produce Response currently would be able to better
>>>>>>>>> declare the actual response entity type, provided the entity types produced share a common ancestor).
>>>>>>>>>
>>>>>>>>> - The main disadvantage I can think of is that generic req/response processing would (if correctly typed) require the
>>>>>>>>> extra "<?>" in many scenarios.
>>>>>>>>>
>>>>>>>>
>>>>>>>> What advantage can that give to the client code, would that interfere with the use of TypeLiteral in Response.getEntity
>>>>>>>> ? Personally I can live with the use of GenericEntity on the server side because IMHO the use of explicit collections is
>>>>>>>> not in 'mainstream', it seems most users are happy with dealing with plain beans - those can be better validated,
>>>>>>>> extended and described
>>>>>>>>
>>>>>>>> Cheers, Sergey
>>>>>>>>
>>>>>>>>> Thoughts?
>>>>>>>>>
>>>>>>>>> Marek
>>>>>>
>>>>>>