[ https://issues.apache.org/jira/browse/ARIES-1342?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Guillaume Nodet resolved ARIES-1342. ------------------------------------ Resolution: Fixed Fix Version/s: proxy-impl-1.0.5 > Aries Proxy Impl fails to proxy a service with covariant type hierarchy in > Java 8 > --------------------------------------------------------------------------------- > > Key: ARIES-1342 > URL: https://issues.apache.org/jira/browse/ARIES-1342 > Project: Aries > Issue Type: Bug > Components: Blueprint > Affects Versions: proxy-impl-1.0.3 > Environment: Karaf 3.0.3/Karaf 4.0.0, JDK 1.8.0_u45 > Reporter: Declan Cox > Assignee: Guillaume Nodet > Priority: Critical > Labels: proxy-impl-1.0.4 > Fix For: proxy-impl-1.0.5 > > Attachments: ARIES-1342.patch, aries-proxy-issue.rar > > > I have a simple type hierarchy with a base interface and an extending > interface with method overriding (covariant return types). A service > implements the derived interface (ColumnDAO - see attached test case). The > attached test case illustrates the scenario. In certain situations AriesProxy > Impl (more specifically the InterfaceCombiningClassAdapter) fails to properly > synthesize the proxy code. In particular it is a combination of the lexical > naming of the classes in the hierarchy and Java 8 method access flags that > does it. The naming of the classes determines the order in which they are > processed since the ProxyClassLoader receives a sorted set of classes when > building the proxy. If that order happens to be such that the types are > processed in hierarchy order starting with the base type, then all is cool. > If not then trouble arises. > Why ? Well if a more derived type is processed then it instruments base > methods which are marked (in Java 8) with Synthetic and Bridge access flags. > In this case the {{visitMethod()}} in {{AbstractWovenProxyAdapter}} does not > generate any code but records the fact that this method has been visited. > When it subsequently visits the base type, the methods are skipped since they > are considered already visited. > In the test case running {{javap -verbose ColumnDAO.class}} yields the > following (note the base type is named ZanyDAO to force the lexical ordering > and thus the error) : > {noformat} > public abstract org.deklanowski.aries.dao.ColumnBatch<R, C, V> prepareBatch(); > flags: ACC_PUBLIC, ACC_ABSTRACT > Signature: #9 // > ()Lorg/deklanowski/aries/dao/ColumnBatch<TR;TC;TV;>; > public abstract org.deklanowski.aries.dao.ColumnQuery<R, C, V> > createQuery(); > flags: ACC_PUBLIC, ACC_ABSTRACT > Signature: #12 // > ()Lorg/deklanowski/aries/dao/ColumnQuery<TR;TC;TV;>; > public org.deklanowski.aries.dao.Batch prepareBatch(); > flags: ACC_PUBLIC, ACC_BRIDGE, ACC_SYNTHETIC > Code: > stack=1, locals=1, args_size=1 > 0: aload_0 > 1: invokeinterface #1, 1 // InterfaceMethod > prepareBatch:()Lorg/deklanowski/aries/dao/ColumnBatch; > 6: areturn > LineNumberTable: > line 3: 0 > LocalVariableTable: > Start Length Slot Name Signature > 0 7 0 this Lorg/deklanowski/aries/dao/ColumnDAO; > LocalVariableTypeTable: > Start Length Slot Name Signature > 0 7 0 this > Lorg/deklanowski/aries/dao/ColumnDAO<TR;TC;TV;>; > public org.deklanowski.aries.dao.Query createQuery(); > flags: ACC_PUBLIC, ACC_BRIDGE, ACC_SYNTHETIC > Code: > stack=1, locals=1, args_size=1 > 0: aload_0 > 1: invokeinterface #2, 1 // InterfaceMethod > createQuery:()Lorg/deklanowski/aries/dao/ColumnQuery; > 6: areturn > LineNumberTable: > line 3: 0 > LocalVariableTable: > Start Length Slot Name Signature > 0 7 0 this Lorg/deklanowski/aries/dao/ColumnDAO; > LocalVariableTypeTable: > Start Length Slot Name Signature > 0 7 0 this > Lorg/deklanowski/aries/dao/ColumnDAO<TR;TC;TV;>; > {noformat} > The logic in the aforementioned {{AbstractWovenProxyAdapter.visitMethod()}} > on line 341 is as follows: > {noformat} > if ((access & (ACC_STATIC | ACC_PRIVATE | ACC_SYNTHETIC > | ACC_NATIVE | ACC_BRIDGE)) == 0 && !!!name.equals("<init>") && > !!!name.equals("<clinit>")) { > <snip> > {noformat} > The if statement evaluates to false and no code is generated though the > methods are recorded as having been visited. -- This message was sent by Atlassian JIRA (v6.3.4#6332)