aries-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Tom Pantelis (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (ARIES-1342) Aries Proxy Impl fails to proxy a service with covariant type hierarchy in Java 8
Date Tue, 08 Mar 2016 11:41:40 GMT

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

Tom Pantelis commented on ARIES-1342:
-------------------------------------

Thanks for committing this. When is proxy-impl-1.0.5 scheduled for release? 

> 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)

Mime
View raw message