If users do want to return List<Bean> and set custom statuses/headers,
then let them do it from out response filters, or get
HttpServletResponse injected.
and on the client side we can do
get(new TypeLiteral<List<Customer>>()), right ?
So IMHO making Response generic will only give an extra headache without
promoting the idea of writing simple response beans
Cheers, Sergey
On 19/10/11 12:41, Sergey Beryozkin wrote:
> Thanks, so I'm wondering why would we want to make an effort and let
> users write
>
> 'public Response<List<Bean>>'
>
> 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
>
>
--
Sergey Beryozkin
http://sberyozkin.blogspot.com
Talend - http://www.talend.com