[
https://issues.apache.org/jira/browse/ARIES-1342?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15183997#comment-15183997
]
Tom Pantelis commented on ARIES-1342:
-------------------------------------
I ran into this issue as well. This is a showstopper for using blueprint. When
will this patch be made available? In proxy-impl-1.0.5? If so when is that
scheduled to release? Or can it be patched to 1.0.4?
The JdkProxyManager handles covariant interfaces correctly although it doesn't
handle classes. How about using the JdkProxyManager for interfaces and the
AsmProxyManager for classes? I prototyped this but then found the
JdkProxyManager and AsmProxyManager classes aren't exported from the proxy-impl
bundle so it wouldn't deploy jn karaf .
I could copy all the code and modify it and build my own bundle or disable the
AsmProxyManager and hope nothing registers services with concrete classes but
neither option is attractive.
> 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
> Priority: Critical
> Labels: proxy-impl-1.0.4
> 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)
