cxf-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sergey Beryozkin <sberyoz...@gmail.com>
Subject Re: Generic JAX-RS service class and generic type resolution
Date Tue, 13 Aug 2013 13:42:57 GMT
Never mind, I reproduced it; still let me know please if your actual 
test code is different,

Thanks, Sergey


On 13/08/13 16:22, Sergey Beryozkin wrote:
> Hi
>
> Does it look like this:
>
> public static class AbstractRestController<T extends RestResource> {
>          @POST
>          public Response add(final T resource) {
>              // build some response
>              return null;
>          }
>      }
>
>      public static class ConcreteRestController extends
>          AbstractRestController<ConcreteRestResource> {
>
>      }
>
> or ConcreteRestController overrides add(...) ?
>
> Thanks, Sergey
>
> On 07/08/13 13:41, Thibaut Robert wrote:
>> Hi!
>>
>> I would like to share a strange behaviour I have with cxf JAX-RS
>> frontend. I am writing a generic JAX-RS service class like this:
>>
>> public class AbstractRestController<T extends RestResource> {
>>      @POST
>>      public Response add(final T resource) { ... }
>> }
>>
>> where RestResource is an interface.
>>
>> Then I use a concrete implementation:
>> public class ConcreteRestController exends
>> AbstractRestController<ConcreteRestResource> { ... }
>>
>> I have an error when a post a request, caused by the way the generic
>> type T is resolved:
>> org.codehaus.jackson.map.JsonMappingException: Can not construct
>> instance of cxfjaxrs.RestResource, problem: abstract types can only be
>> instantiated with additional type information
>>
>> T is resolved as RestResource instead of ConcreteRestResource.
>>
>> I found out that in the method InjectionUtils.getSuperType(), it
>> prefers using the type parameter bound when present, instead of
>> calculating the real type argument. Is there any motivation beyond
>> this ? In this case, the actual argument type can be determined at
>> runtime, and is better that the parameter bound.
>>
>> I got things working by using this trick: public class
>> AbstractRestController<T extends Object & RestResource> (because in
>> this case it only considers the first bound, and thus go beyond to
>> find a type more precise than Object)
>>
>> Is there any way to fix this ?
>>
>> I tested with 2.7.7-SNAPSHOT and 3.0.0-SNAPSHOT. Things works out of
>> the box with Jersey.
>>
>> BR,
>> Thibaut
>>



Mime
View raw message