Łukasz Dywicki created CXF-7279:
-----------------------------------

             Summary: Leaky generic type resolver doesn't work with more than 1 
parameter
                 Key: CXF-7279
                 URL: https://issues.apache.org/jira/browse/CXF-7279
             Project: CXF
          Issue Type: Bug
          Components: JAX-RS
    Affects Versions: 3.1.9
            Reporter: Łukasz Dywicki


When resource type is generic and declares more than one type parameter and 
some of other parameters are used as return type together with collection CXF 
always returns first resource parameter.

For example resource such this:
{code:lang=java}
interface DocumentResource<ID, T extends Document<ID>> {
    Set<T> getDocuments(ID id);
}

class DocumentResourceImpl<String, Document<String>> {
    Set<Document<String>> getDocument() {
         // just normal implementation
    }
}
{code}

Fails miserably with 3.1.9. Reason why it fails is leaky logic in 
InjectionUtils:
{code:lang=java|title=InjectionUtils.java lines 1451-1455}
TypeVariable<?> typeVar = 
(TypeVariable<?>)((ParameterizedType)type).getActualTypeArguments()[0];
Type theType = InjectionUtils.getSuperType(serviceCls, typeVar);
Class<?> cls = theType instanceof Class
    ? (Class<?>)theType : InjectionUtils.getActualType(theType, 0);
type = new ParameterizedCollectionType(cls);
{code}

CXF properly discovers type variables but incorrectly assumes that actual 
collection bound comes as first type parameter. This leads to assumption that 
return type is Collection<String> instead of Collection<Document<String>>.
Sadly I am not able to patch this code myself because (I think) it requires 
switching completely to generic type names instead of indexes. This part of 
code is just getting 4 years old and I believe there is few dead bodies there. 
;-)

An note here that it used to work with CXF 2.2.7 or some later release thus 
this seems to be an regression bug.

I checked how jackson classmate handles that and it manages to resolve all type 
bounds properly.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Reply via email to