I'm off till 31st Oct so I'll generate a bit of more noise in this
thread :-)
Basically I think the solution has to be complete and also minimalistic
if possible.
Response<T> is a step forward as far as the tooling is concerned which
is good, but it's not complete and I'm not yet sure what effect it will
have on the client side and the use of existing GenericEntity & TypeLiteral.
Using the annotations is not complete in that it won't support List<T> -
but may be it's not a bad thing, auto-creating a schema for List<Bar> is
problematic especially when the JAX-RS implementations allow for the
customization of the wrapper names and namespaces.
May be both options can be combined, Response<T> and annotations, not sure
Sergey
On 25/10/11 22:34, Sergey Beryozkin wrote:
>>
>>>
>>> What the tool can do with '? extends Bar' ?.
>>
>> Again, I don't think this is the norm. But of course this wouldn't
>> help the tool as much.
>
> We have many many cases where users are asking how to do XmlSeeAlso
> added and we have a feature which allows to handle additional JAXB
> contexts, specifically to handle such cases, based on the demand
>
>>
>>>
>>> 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.
>>
>> How does that annotation look like? For the case in which wildcards
>> are needed in Java types, I'd expect that annotation to be quite
>> hairy. Is it not?
>>
> Does it have to be hairy ?
> How about
> @ResponseClasses {
> @ResponseClass(A.class)
> @ResponseClass(B.class)
> }
>
> or
>
> @ResponseClass(A.class)
>
>
> Note I'm not that strongly opposed to Response<Bar> - I'm just feeling
> possibly wrongly that could make things a bit messier - may be I'm wrong
>
> Sergey
>
>
>> -- Santiago
>>
>>>
>>> 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
>>>>>>>>>
>>>>>>>>>
>>
>
>
--
Sergey Beryozkin
http://sberyozkin.blogspot.com
Talend - http://www.talend.com