[
https://issues.apache.org/jira/browse/ARIES-1342?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16002484#comment-16002484
]
ASF subversion and git services commented on ARIES-1342:
--------------------------------------------------------
Commit 1794535 from [~gzres] in branch 'aries/trunk'
[ https://svn.apache.org/r1794535 ]
[ARIES-1618][ARIES-1342] Better sorting of separate interface hierarchies
(+test)
> 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.15#6346)
