Ok, I'll give it a try. How often are the snapshots published ?
On Wed, Aug 14, 2013 at 4:46 PM, Sergey Beryozkin <[email protected]> wrote: > Hi Robert > > I'm hoping I've fixed it as part of > https://issues.apache.org/jira/browse/CXF-5204 > > Please try the snapshots a bit later on > Thanks, Sergey > > > On 14/08/13 09:52, Sergey Beryozkin wrote: >> >> Hi >> >> I'm on it - need to add few more tests only. TypeVariable handling is >> wrong at the moment, it checks bounds too early, as you implied >> yourself, it works OK with some signature variants, but fails in this >> particular case, so I'm just pushing the bounds check down >> >> Cheers, Sergey >> On 13/08/13 18:00, Thibaut Robert wrote: >>> >>> BTW I also noticed later on an other issue with the following generic >>> method, but only when using xml: >>> @GET >>> public Collection<T> list() { >>> return resources.values(); //resources is a HashMap<String,T> >>> } >>> >>> I think I got a "No body writer for type Collection.Values" error. >>> (ConcreteRestResource was annotated as @XmlRootElement) >>> That's not so important for me as I can stick to json. Again in this >>> case jersey was handling it correctly. >>> >>> I have a test project somewhere if you want to look at it and need >>> more details. >>> >>> On Tue, Aug 13, 2013 at 4:45 PM, Thibaut Robert >>> <[email protected]> wrote: >>>> >>>> Yes, it looks like what you wrote (no overriding) >>>> Thanks for taking time looking into this. >>>> >>>> Thibaut >>>> >>>> On Tue, Aug 13, 2013 at 3:42 PM, Sergey Beryozkin >>>> <[email protected]> wrote: >>>>> >>>>> 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 >>>>>>> >>>>> >>>>> >> >
