cxf-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Łukasz Dywicki (JIRA) <j...@apache.org>
Subject [jira] [Commented] (CXF-7279) Leaky generic type resolver doesn't work with more than 1 parameter
Date Sat, 11 Mar 2017 00:56:04 GMT

    [ https://issues.apache.org/jira/browse/CXF-7279?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15905952#comment-15905952
] 

Łukasz Dywicki commented on CXF-7279:
-------------------------------------

An older issue related to similar bug.

> 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
>              Labels: regression
>
> 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)

Mime
View raw message