[jira] [Commented] (ARIES-1341) JpaBeanProcessor not working in karaf
[ https://issues.apache.org/jira/browse/ARIES-1341?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14610781#comment-14610781 ] Michał Woś commented on ARIES-1341: --- OK. I found out where the problem lies. Karaf has two features named persistence-api (version 2.0.0 and 2.1.0). First depends on genorimo specs (javax.persistence;version=1.1). Second depends on hibernate api (javax.persistence;version=2.1.0). According to features.xml of karaf jpa feature can work with both persistence-api 's (feature version=[2.0.0,2.2.0) prerequisite=false dependency=falsepersistence-api/feature). That means aries jpa wires with latest package of javax.persistence whereas anything that is dependant on geronimo specs wires with 1.1 version. That actually caused getAnnotation() and reflection issues. I had same classes loaded twice because I had wirings to same package in 2 different versions. Aries wired to latest (2.1.0), my bundle wired to 1.1. Sorry for wasting your time on that but it really looked like aries issue. Now it seems rather to karaf issue as it permits to have same package in 2 different versions. This means this issue is an improvement. What should be done is: * only top level class is scanned. super classes are not * adding support to annotate classes and methods * scanning shouldn't stop when first field/method is found. we can have multiple persistence units in one class As for the transaction annotation, I had a solution written myself so far but I saw an example using tx:enable-annotations /. I will give it a try. JpaBeanProcessor not working in karaf - Key: ARIES-1341 URL: https://issues.apache.org/jira/browse/ARIES-1341 Project: Aries Issue Type: Improvement Components: Blueprint, JPA Affects Versions: jpa-2.0.0 Environment: karaf-4.0.0, java 8 Reporter: Michał Woś Assignee: Christian Schneider Fix For: jpa-2.1.0, jpa-2.0.1 * getAnnotation() return null because annotations are proxied (com.sun.proxy). * only top level class is scanned. super classes are not * only fields are scanned whereas target of persistence annotations is: TYPE, METHOD, FIELD * Setting persistence fields results in: Can not set javax.persistence.EntityManager field xxx to com.sun.proxy.$Proxy37 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (ARIES-1342) Aries Proxy Impl fails to proxy covariant type hierarchy in Java 8
Declan Cox created ARIES-1342:
-
Summary: Aries Proxy Impl fails to proxy 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
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. No code is
generated due to the logic implemented here and the way Java 8 generates access
flags in this case.
In the test case running javap -verbose on the derived type yields the
following (note the base type is named ZanyDAO to force the lexical ordering
and thus the error) :
{{
public abstract org.deklanowski.aries.dao.ColumnBatchR, C, V prepareBatch();
flags: ACC_PUBLIC, ACC_ABSTRACT
Signature: #9 //
()Lorg/deklanowski/aries/dao/ColumnBatchTR;TC;TV;;
public abstract org.deklanowski.aries.dao.ColumnQueryR, C, V createQuery();
flags: ACC_PUBLIC, ACC_ABSTRACT
Signature: #12 //
()Lorg/deklanowski/aries/dao/ColumnQueryTR;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/ColumnDAOTR;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/ColumnDAOTR;TC;TV;;
}}
The logic in the aforementioned {{AbstractWovenProxyAdapter.visitMethod()}} on
line 341 is as follows:
{{
if ((access (ACC_STATIC | ACC_PRIVATE | ACC_SYNTHETIC
| ACC_NATIVE | ACC_BRIDGE)) == 0 !!!name.equals(init)
!!!name.equals(clinit)) {
}}
The if statement evaluates to false and no code is generated though the method
descriptions are recorded as having been visited.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (ARIES-1342) Aries Proxy Impl fails to proxy covariant type hierarchy in Java 8
[
https://issues.apache.org/jira/browse/ARIES-1342?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Declan Cox updated ARIES-1342:
--
Description:
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. No code is
generated due to the logic implemented here and the way Java 8 generates access
flags in this case.
In the test case running javap -verbose on the derived type yields the
following (note the base type is named ZanyDAO to force the lexical ordering
and thus the error) :
{{
public abstract org.deklanowski.aries.dao.ColumnBatchR, C, V prepareBatch();
flags: ACC_PUBLIC, ACC_ABSTRACT
Signature: #9 //
()Lorg/deklanowski/aries/dao/ColumnBatchTR;TC;TV;;
public abstract org.deklanowski.aries.dao.ColumnQueryR, C, V createQuery();
flags: ACC_PUBLIC, ACC_ABSTRACT
Signature: #12 //
()Lorg/deklanowski/aries/dao/ColumnQueryTR;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/ColumnDAOTR;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/ColumnDAOTR;TC;TV;;
}}
The logic in the aforementioned {{AbstractWovenProxyAdapter.visitMethod()}} on
line 341 is as follows:
{{
if ((access (ACC_STATIC | ACC_PRIVATE | ACC_SYNTHETIC
| ACC_NATIVE | ACC_BRIDGE)) == 0 !!!name.equals(init)
!!!name.equals(clinit)) {
}}
The if statement evaluates to false and no code is generated though the method
descriptions are recorded as having been visited.
was:
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. No code
[jira] [Updated] (ARIES-1342) Aries Proxy Impl fails to proxy covariant type hierarchy in Java 8
[
https://issues.apache.org/jira/browse/ARIES-1342?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Declan Cox updated ARIES-1342:
--
Attachment: aries-proxy-issue.rar
Small maven project which illustrates issue. Changing name of ZanyDAO to
BaseDAO in dao module corrects type processing order.
There is also a karaf features module which will allow you to recreate this on
Karaf 3.x/4.x easily.
Aries Proxy Impl fails to proxy 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-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. No
code is generated due to the logic implemented here and the way Java 8
generates access flags in this case.
In the test case running javap -verbose on the derived type yields the
following (note the base type is named ZanyDAO to force the lexical ordering
and thus the error) :
{{
public abstract org.deklanowski.aries.dao.ColumnBatchR, C, V
prepareBatch();
flags: ACC_PUBLIC, ACC_ABSTRACT
Signature: #9 //
()Lorg/deklanowski/aries/dao/ColumnBatchTR;TC;TV;;
public abstract org.deklanowski.aries.dao.ColumnQueryR, C, V
createQuery();
flags: ACC_PUBLIC, ACC_ABSTRACT
Signature: #12 //
()Lorg/deklanowski/aries/dao/ColumnQueryTR;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/ColumnDAOTR;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/ColumnDAOTR;TC;TV;;
}}
The logic in the aforementioned {{AbstractWovenProxyAdapter.visitMethod()}}
on line 341 is as follows:
{{
if ((access (ACC_STATIC | ACC_PRIVATE | ACC_SYNTHETIC
| ACC_NATIVE | ACC_BRIDGE)) == 0 !!!name.equals(init)
!!!name.equals(clinit)) {
}}
The if statement evaluates to false and no code is generated though the
method descriptions are recorded as having been visited.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (ARIES-1342) Aries Proxy Impl fails to proxy a service with covariant type hierarchy in Java 8
[
https://issues.apache.org/jira/browse/ARIES-1342?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Declan Cox updated ARIES-1342:
--
Description:
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.ColumnBatchR, C, V prepareBatch();
flags: ACC_PUBLIC, ACC_ABSTRACT
Signature: #9 //
()Lorg/deklanowski/aries/dao/ColumnBatchTR;TC;TV;;
public abstract org.deklanowski.aries.dao.ColumnQueryR, C, V createQuery();
flags: ACC_PUBLIC, ACC_ABSTRACT
Signature: #12 //
()Lorg/deklanowski/aries/dao/ColumnQueryTR;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/ColumnDAOTR;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/ColumnDAOTR;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.
was:
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
[jira] [Commented] (ARIES-1341) JpaBeanProcessor not working in karaf
[ https://issues.apache.org/jira/browse/ARIES-1341?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14610216#comment-14610216 ] Michał Woś commented on ARIES-1341: --- I don't have simple example that could be attached. Steps to reproduce in my case: - create bundle with a bean that injects PersistenceContext and has methods annotated with Transaction annotation - in my case this bean is also an osgi service - compile code with java 8 - install bundle in karaf-4.0.0 also running with java 8 BTW: I am trying to update JpaBeanProcessor code to have it working in my env. As soon as I have it working I will attach sources. JpaBeanProcessor not working in karaf - Key: ARIES-1341 URL: https://issues.apache.org/jira/browse/ARIES-1341 Project: Aries Issue Type: Improvement Components: Blueprint, JPA Affects Versions: jpa-2.0.0 Environment: karaf-4.0.0, java 8 Reporter: Michał Woś Assignee: Christian Schneider Fix For: jpa-2.1.0, jpa-2.0.1 * getAnnotation() return null because annotations are proxied (com.sun.proxy). * only top level class is scanned. super classes are not * only fields are scanned whereas target of persistence annotations is: TYPE, METHOD, FIELD * Setting persistence fields results in: Can not set javax.persistence.EntityManager field xxx to com.sun.proxy.$Proxy37 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (ARIES-1342) Aries Proxy Impl fails to proxy covariant type hierarchy in Java 8
[
https://issues.apache.org/jira/browse/ARIES-1342?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Declan Cox updated ARIES-1342:
--
Description:
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. No code is
generated due to the logic implemented here and the way Java 8 generates access
flags in this case.
In the test case running javap -verbose on the derived type 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.ColumnBatchR, C, V prepareBatch();
flags: ACC_PUBLIC, ACC_ABSTRACT
Signature: #9 //
()Lorg/deklanowski/aries/dao/ColumnBatchTR;TC;TV;;
public abstract org.deklanowski.aries.dao.ColumnQueryR, C, V createQuery();
flags: ACC_PUBLIC, ACC_ABSTRACT
Signature: #12 //
()Lorg/deklanowski/aries/dao/ColumnQueryTR;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/ColumnDAOTR;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/ColumnDAOTR;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 method
descriptions are recorded as having been visited.
was:
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
Re: [VOTE] blueprint-parser-1.3.1, blueprint-noosgi-1.1.1, blueprint-web-1.1.1 releases
Hi Tom I think it is onlt the 2nd time I'm doing an Aries release, may be 3rd, the last time it was a new module, so only this time, when I looked at release few blueprint modules did I find myself about -Pdev, I saw the dev profile properties before but never thouyght about why one would use them until I checked the Aries Blueprint section. I think it is reasonable to use -Pdev for a short period of time, though it s obviously the responsibility of the current release manager to ensure -Pdev works :-). I guess it's been relied upon in few cases before. Perhaps it makes sense to have a dedicated dev discussion about various release strategies, the parent pom one, vs -Pdev, etc Thanks, Sergey On 01/07/15 13:25, Thomas Watson wrote: I must confess that I did not know about this -Pdev option. Is that only needed when we are in this release limbo period? Tom From: Sergey Beryozkin sberyoz...@gmail.com To: dev@aries.apache.org Date: 06/30/2015 04:24 PM Subject:Re: [VOTE] blueprint-parser-1.3.1, blueprint-noosgi-1.1.1, blueprint-web-1.1.1 releases Building with -Pdev is OK now, sorry I did not update all the properties immediately. As a side note a number of other dev properties have been out of sync... Thanks, Sergey On 30/06/15 21:41, Sergey Beryozkin wrote: I was concerned myself, then I checked the Aries release instructions and one option listed was to make sure the (dev) profile gets updated which is what I did. However I only updated dev properties in the released module poms - let me check the whole trunk Sergey On 30/06/15 20:15, Thomas Watson wrote: Is the intent to leave trunk broken for building while the votes are going on? Right now I can no longer build trunk because it complains about not finding the these soon to be released artifacts. Tom From: David Bosschaert david.bosscha...@gmail.com To: dev@aries.apache.org dev@aries.apache.org Date: 06/30/2015 01:31 PM Subject:Re: [VOTE] blueprint-parser-1.3.1, blueprint-noosgi-1.1.1, blueprint-web-1.1.1 releases +1 David On 29 June 2015 at 16:56, Sergey Beryozkin sberyoz...@gmail.com wrote: Hi All This is a vote to support the release of blueprint-parser-1.3.1, blueprint-noosgi-1.1.1, blueprint-web 1.1.1. The staging repository for blueprint-parser-1.3.1 is at https://repository.apache.org/content/repositories/orgapachearies-1027 The staging repository for blueprint-noosgi-1.1.1 and blueprint-web-1.1.1 is at https://repository.apache.org/content/repositories/orgapachearies-1028 The following issues have been addressed: https://issues.apache.org/jira/browse/ARIES-1322 https://issues.apache.org/jira/browse/ARIES-1323 https://issues.apache.org/jira/browse/ARIES-1334 A servlet-based deployment of Blueprint contexts with custom namespace handlers will work better in non OSGI environments after the release. The vote is open for the next 72 hours, here is my +1, Thanks, Sergey
[jira] [Updated] (ARIES-1342) Aries Proxy Impl fails to proxy a service with covariant type hierarchy in Java 8
[
https://issues.apache.org/jira/browse/ARIES-1342?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Declan Cox updated ARIES-1342:
--
Summary: Aries Proxy Impl fails to proxy a service with covariant type
hierarchy in Java 8 (was: Aries Proxy Impl fails to proxy covariant type
hierarchy in Java 8)
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-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. No
code is generated due to the logic implemented here and the way Java 8
generates access flags in this case.
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.ColumnBatchR, C, V prepareBatch();
flags: ACC_PUBLIC, ACC_ABSTRACT
Signature: #9 //
()Lorg/deklanowski/aries/dao/ColumnBatchTR;TC;TV;;
public abstract org.deklanowski.aries.dao.ColumnQueryR, C, V
createQuery();
flags: ACC_PUBLIC, ACC_ABSTRACT
Signature: #12 //
()Lorg/deklanowski/aries/dao/ColumnQueryTR;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/ColumnDAOTR;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/ColumnDAOTR;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
method descriptions are recorded as having been visited.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (ARIES-1342) Aries Proxy Impl fails to proxy covariant type hierarchy in Java 8
[
https://issues.apache.org/jira/browse/ARIES-1342?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Declan Cox updated ARIES-1342:
--
Description:
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. No code is
generated due to the logic implemented here and the way Java 8 generates access
flags in this case.
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.ColumnBatchR, C, V prepareBatch();
flags: ACC_PUBLIC, ACC_ABSTRACT
Signature: #9 //
()Lorg/deklanowski/aries/dao/ColumnBatchTR;TC;TV;;
public abstract org.deklanowski.aries.dao.ColumnQueryR, C, V createQuery();
flags: ACC_PUBLIC, ACC_ABSTRACT
Signature: #12 //
()Lorg/deklanowski/aries/dao/ColumnQueryTR;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/ColumnDAOTR;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/ColumnDAOTR;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 method
descriptions are recorded as having been visited.
was:
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
[jira] [Updated] (ARIES-1342) Aries Proxy Impl fails to proxy a service with covariant type hierarchy in Java 8
[
https://issues.apache.org/jira/browse/ARIES-1342?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Declan Cox updated ARIES-1342:
--
Description:
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, no code 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.ColumnBatchR, C, V prepareBatch();
flags: ACC_PUBLIC, ACC_ABSTRACT
Signature: #9 //
()Lorg/deklanowski/aries/dao/ColumnBatchTR;TC;TV;;
public abstract org.deklanowski.aries.dao.ColumnQueryR, C, V createQuery();
flags: ACC_PUBLIC, ACC_ABSTRACT
Signature: #12 //
()Lorg/deklanowski/aries/dao/ColumnQueryTR;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/ColumnDAOTR;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/ColumnDAOTR;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 method
descriptions are recorded as having been visited.
was:
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
[jira] [Updated] (ARIES-1342) Aries Proxy Impl fails to proxy a service with covariant type hierarchy in Java 8
[
https://issues.apache.org/jira/browse/ARIES-1342?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Declan Cox updated ARIES-1342:
--
Description:
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.ColumnBatchR, C, V prepareBatch();
flags: ACC_PUBLIC, ACC_ABSTRACT
Signature: #9 //
()Lorg/deklanowski/aries/dao/ColumnBatchTR;TC;TV;;
public abstract org.deklanowski.aries.dao.ColumnQueryR, C, V createQuery();
flags: ACC_PUBLIC, ACC_ABSTRACT
Signature: #12 //
()Lorg/deklanowski/aries/dao/ColumnQueryTR;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/ColumnDAOTR;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/ColumnDAOTR;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 method
descriptions are recorded as having been visited.
was:
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
[jira] [Created] (ARIES-1341) JpaBeanProcessor not working in karaf
Michał Woś created ARIES-1341: - Summary: JpaBeanProcessor not working in karaf Key: ARIES-1341 URL: https://issues.apache.org/jira/browse/ARIES-1341 Project: Aries Issue Type: Bug Components: Blueprint, JPA Affects Versions: jpa-2.0.0 Environment: karaf-4.0.0 Reporter: Michał Woś Priority: Critical * getAnnotation() return null because annotations are proxied (com.sun.proxy). * only top level class is scanned. super classes are not * only fields are scanned whereas target of persistence annotations is: TYPE, METHOD, FIELD -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (ARIES-1341) JpaBeanProcessor not working in karaf
[ https://issues.apache.org/jira/browse/ARIES-1341?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14610045#comment-14610045 ] Christian Schneider commented on ARIES-1341: So this might indeed be a bug. I can not reproduce it though. In the examples the class to be injected was not a proxy. So I assume that you are using this in a different way. Can you describe exactly what you did to get the exception? Ideally with the code you used? JpaBeanProcessor not working in karaf - Key: ARIES-1341 URL: https://issues.apache.org/jira/browse/ARIES-1341 Project: Aries Issue Type: Improvement Components: Blueprint, JPA Affects Versions: jpa-2.0.0 Environment: karaf-4.0.0, java 8 Reporter: Michał Woś Assignee: Christian Schneider Fix For: jpa-2.1.0, jpa-2.0.1 * getAnnotation() return null because annotations are proxied (com.sun.proxy). * only top level class is scanned. super classes are not * only fields are scanned whereas target of persistence annotations is: TYPE, METHOD, FIELD * Setting persistence fields results in: Can not set javax.persistence.EntityManager field xxx to com.sun.proxy.$Proxy37 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (ARIES-1341) JpaBeanProcessor not working in karaf
[ https://issues.apache.org/jira/browse/ARIES-1341?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schneider reassigned ARIES-1341: -- Assignee: Christian Schneider JpaBeanProcessor not working in karaf - Key: ARIES-1341 URL: https://issues.apache.org/jira/browse/ARIES-1341 Project: Aries Issue Type: Bug Components: Blueprint, JPA Affects Versions: jpa-2.0.0 Environment: karaf-4.0.0 Reporter: Michał Woś Assignee: Christian Schneider Priority: Critical * getAnnotation() return null because annotations are proxied (com.sun.proxy). * only top level class is scanned. super classes are not * only fields are scanned whereas target of persistence annotations is: TYPE, METHOD, FIELD * Setting persistence fields results in: Can not set javax.persistence.EntityManager field xxx to com.sun.proxy.$Proxy37 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (ARIES-1341) JpaBeanProcessor not working in karaf
[ https://issues.apache.org/jira/browse/ARIES-1341?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14610035#comment-14610035 ] Christian Schneider commented on ARIES-1341: About getAnnotations(). Can you post some example where that exception occured? Did it occur inside the aries code or when you tried to access the bean with your own code to introspect the annotations? JpaBeanProcessor not working in karaf - Key: ARIES-1341 URL: https://issues.apache.org/jira/browse/ARIES-1341 Project: Aries Issue Type: Improvement Components: Blueprint, JPA Affects Versions: jpa-2.0.0 Environment: karaf-4.0.0, java 8 Reporter: Michał Woś Assignee: Christian Schneider Fix For: jpa-2.1.0, jpa-2.0.1 * getAnnotation() return null because annotations are proxied (com.sun.proxy). * only top level class is scanned. super classes are not * only fields are scanned whereas target of persistence annotations is: TYPE, METHOD, FIELD * Setting persistence fields results in: Can not set javax.persistence.EntityManager field xxx to com.sun.proxy.$Proxy37 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (ARIES-1341) JpaBeanProcessor not working in karaf
[ https://issues.apache.org/jira/browse/ARIES-1341?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michał Woś updated ARIES-1341: -- Environment: karaf-4.0.0, java 8 (was: karaf-4.0.0) JpaBeanProcessor not working in karaf - Key: ARIES-1341 URL: https://issues.apache.org/jira/browse/ARIES-1341 Project: Aries Issue Type: Improvement Components: Blueprint, JPA Affects Versions: jpa-2.0.0 Environment: karaf-4.0.0, java 8 Reporter: Michał Woś Assignee: Christian Schneider Fix For: jpa-2.1.0, jpa-2.0.1 * getAnnotation() return null because annotations are proxied (com.sun.proxy). * only top level class is scanned. super classes are not * only fields are scanned whereas target of persistence annotations is: TYPE, METHOD, FIELD * Setting persistence fields results in: Can not set javax.persistence.EntityManager field xxx to com.sun.proxy.$Proxy37 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (ARIES-1341) JpaBeanProcessor not working in karaf
[ https://issues.apache.org/jira/browse/ARIES-1341?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14609981#comment-14609981 ] Christian Schneider commented on ARIES-1341: I switched this to improvement as we have working examples. So the functionality is not broken. It is just not as complete as it could be. Your are describing several things here. The ones that are clear to me are: - only top level class scanned, super classes are not. I think it is a good enhancement to support that case too. As people might want to put the EntityManager into a parent class. - only fields are scanned As far as I know fields are the typical place to put the annotation. Methods could be implemented but I am not sure what the gain would be. I am fine if the added complexity is not too high. I am not sure what for example @PersistenceContext on a type would mean. So could you give an example of how this would work? I do not fully understand the other two issues: - getAnnotation will not work on the blueprint bean as it is proxied. In what context would you need that? - setting persistence fields.. Again could you explain what your use case is there? JpaBeanProcessor not working in karaf - Key: ARIES-1341 URL: https://issues.apache.org/jira/browse/ARIES-1341 Project: Aries Issue Type: Improvement Components: Blueprint, JPA Affects Versions: jpa-2.0.0 Environment: karaf-4.0.0 Reporter: Michał Woś Assignee: Christian Schneider Fix For: jpa-2.1.0, jpa-2.0.1 * getAnnotation() return null because annotations are proxied (com.sun.proxy). * only top level class is scanned. super classes are not * only fields are scanned whereas target of persistence annotations is: TYPE, METHOD, FIELD * Setting persistence fields results in: Can not set javax.persistence.EntityManager field xxx to com.sun.proxy.$Proxy37 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (ARIES-1341) JpaBeanProcessor not working in karaf
[
https://issues.apache.org/jira/browse/ARIES-1341?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14610038#comment-14610038
]
Michał Woś commented on ARIES-1341:
---
inside aries, JpaBeanProcessor
private Field getPersistenceField(Class? c) {
for (Field field : c.getDeclaredFields()) {
if (field.getAnnotation(PersistenceContext.class) != null) {
return field;
}
if (field.getAnnotation(PersistenceUnit.class) != null) {
return field;
}
}
return null;
}
field.getAnnotation(xxx) always returns null due to proxies
all issues are noticed in JpaBeanProcessor
JpaBeanProcessor not working in karaf
-
Key: ARIES-1341
URL: https://issues.apache.org/jira/browse/ARIES-1341
Project: Aries
Issue Type: Improvement
Components: Blueprint, JPA
Affects Versions: jpa-2.0.0
Environment: karaf-4.0.0, java 8
Reporter: Michał Woś
Assignee: Christian Schneider
Fix For: jpa-2.1.0, jpa-2.0.1
* getAnnotation() return null because annotations are proxied (com.sun.proxy).
* only top level class is scanned. super classes are not
* only fields are scanned whereas target of persistence annotations is: TYPE,
METHOD, FIELD
* Setting persistence fields results in:
Can not set javax.persistence.EntityManager field xxx to
com.sun.proxy.$Proxy37
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
Re: [VOTE] blueprint-parser-1.3.1, blueprint-noosgi-1.1.1, blueprint-web-1.1.1 releases
Hi Sergey, we might also look into trying to include the staging repository into the poms when doing releases for several bundles. I am not sure what downsides there may be but it could help Christian On 01.07.2015 15:15, Sergey Beryozkin wrote: Hi Tom I think it is onlt the 2nd time I'm doing an Aries release, may be 3rd, the last time it was a new module, so only this time, when I looked at release few blueprint modules did I find myself about -Pdev, I saw the dev profile properties before but never thouyght about why one would use them until I checked the Aries Blueprint section. I think it is reasonable to use -Pdev for a short period of time, though it s obviously the responsibility of the current release manager to ensure -Pdev works :-). I guess it's been relied upon in few cases before. Perhaps it makes sense to have a dedicated dev discussion about various release strategies, the parent pom one, vs -Pdev, etc Thanks, Sergey -- Christian Schneider http://www.liquid-reality.de Open Source Architect http://www.talend.com
[jira] [Comment Edited] (ARIES-1342) Aries Proxy Impl fails to proxy a service with covariant type hierarchy in Java 8
[
https://issues.apache.org/jira/browse/ARIES-1342?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14610446#comment-14610446
]
Declan Cox edited comment on ARIES-1342 at 7/1/15 3:19 PM:
---
BTW the exception that you will see that heralded all of this was as follows:
*java.lang.ClassFormatError: Absent Code attribute in method that is not native
or abstract in class file Proxy82522026_baad_4ad4_a237_03b60effcd46*
{noformat}
2015-07-01 17:16:10,348 | ERROR | pool-43-thread-1 | BlueprintContainerImpl
| 12 - org.apache.aries.blueprint.core - 1.4.3 | Unable to start
blueprint container for bundle org.deklanowski.aries.consumer
org.osgi.service.blueprint.container.ComponentDefinitionException:
org.apache.aries.proxy.UnableToProxyException: java.lang.ClassFormatError:
Absent Code attribute in method that is not native or abstract in class file
Proxy82522026_baad_4ad4_a237_03b60effcd46
at
org.apache.aries.blueprint.container.ReferenceRecipe.internalCreate(ReferenceRecipe.java:122)[12:org.apache.aries.blueprint.core:1.4.3]
at
org.apache.aries.blueprint.di.AbstractRecipe$1.call(AbstractRecipe.java:79)[12:org.apache.aries.blueprint.core:1.4.3]
at java.util.concurrent.FutureTask.run(FutureTask.java:266)[:1.8.0_45]
at
org.apache.aries.blueprint.di.AbstractRecipe.create(AbstractRecipe.java:88)[12:org.apache.aries.blueprint.core:1.4.3]
at
org.apache.aries.blueprint.container.BlueprintRepository.createInstances(BlueprintRepository.java:245)[12:org.apache.aries.blueprint.core:1.4.3]
at
org.apache.aries.blueprint.container.BlueprintRepository.createAll(BlueprintRepository.java:183)[12:org.apache.aries.blueprint.core:1.4.3]
at
org.apache.aries.blueprint.container.BlueprintContainerImpl.instantiateEagerComponents(BlueprintContainerImpl.java:682)[12:org.apache.aries.blueprint.core:1.4.3]
at
org.apache.aries.blueprint.container.BlueprintContainerImpl.doRun(BlueprintContainerImpl.java:377)[12:org.apache.aries.blueprint.core:1.4.3]
at
org.apache.aries.blueprint.container.BlueprintContainerImpl.run(BlueprintContainerImpl.java:269)[12:org.apache.aries.blueprint.core:1.4.3]
at
org.apache.aries.blueprint.container.BlueprintExtender.createContainer(BlueprintExtender.java:294)[12:org.apache.aries.blueprint.core:1.4.3]
at
org.apache.aries.blueprint.container.BlueprintExtender.createContainer(BlueprintExtender.java:263)[12:org.apache.aries.blueprint.core:1.4.3]
at
org.apache.aries.blueprint.container.BlueprintExtender.modifiedBundle(BlueprintExtender.java:253)[12:org.apache.aries.blueprint.core:1.4.3]
at
org.apache.aries.util.tracker.hook.BundleHookBundleTracker$Tracked.customizerModified(BundleHookBundleTracker.java:500)[21:org.apache.aries.util:1.1.0]
at
org.apache.aries.util.tracker.hook.BundleHookBundleTracker$Tracked.customizerModified(BundleHookBundleTracker.java:433)[21:org.apache.aries.util:1.1.0]
at
org.apache.aries.util.tracker.hook.BundleHookBundleTracker$AbstractTracked.track(BundleHookBundleTracker.java:725)[21:org.apache.aries.util:1.1.0]
at
org.apache.aries.util.tracker.hook.BundleHookBundleTracker$Tracked.bundleChanged(BundleHookBundleTracker.java:463)[21:org.apache.aries.util:1.1.0]
at
org.apache.aries.util.tracker.hook.BundleHookBundleTracker$BundleEventHook.event(BundleHookBundleTracker.java:422)[21:org.apache.aries.util:1.1.0]
at
org.apache.felix.framework.util.SecureAction.invokeBundleEventHook(SecureAction.java:1179)[org.apache.felix.framework-5.0.1.jar:]
at
org.apache.felix.framework.util.EventDispatcher.createWhitelistFromHooks(EventDispatcher.java:730)[org.apache.felix.framework-5.0.1.jar:]
at
org.apache.felix.framework.util.EventDispatcher.fireBundleEvent(EventDispatcher.java:485)[org.apache.felix.framework-5.0.1.jar:]
at
org.apache.felix.framework.Felix.fireBundleEvent(Felix.java:4544)[org.apache.felix.framework-5.0.1.jar:]
at
org.apache.felix.framework.Felix.startBundle(Felix.java:2166)[org.apache.felix.framework-5.0.1.jar:]
at
org.apache.felix.framework.BundleImpl.start(BundleImpl.java:977)[org.apache.felix.framework-5.0.1.jar:]
at
org.apache.felix.framework.BundleImpl.start(BundleImpl.java:964)[org.apache.felix.framework-5.0.1.jar:]
at
org.apache.karaf.features.internal.service.FeaturesServiceImpl.startBundle(FeaturesServiceImpl.java:1189)[8:org.apache.karaf.features.core:4.0.0]
at
org.apache.karaf.features.internal.service.Deployer.deploy(Deployer.java:830)[8:org.apache.karaf.features.core:4.0.0]
at
org.apache.karaf.features.internal.service.FeaturesServiceImpl.doProvision(FeaturesServiceImpl.java:1079)[8:org.apache.karaf.features.core:4.0.0]
at
Re: [VOTE] Release Aries Subsystems 2.0.2
+1 Christian On 30.06.2015 09:24, dav...@apache.org wrote: Hi, Subsystems 2.0.1 was released yesterday, but it contained a serious bug which made it not usable with the Felix Bundle Repository implementation. Therefore I'm calling a vote on Subsystems 2.0.2, which has this issue resolved. The following modules are part of this release: subsystem-api 2.0.2 subsystem-core 2.0.2 subsystem-bundle 2.0.2 The following bug was fixed since Subsystems 2.0.1: ARIES-1339 - IllegalAccessException when installing a new subsystem Staging repository: https://repository.apache.org/content/repositories/orgapachearies-1029 More information about Aries Subsystems: http://aries.apache.org/modules/subsystems.html Please vote: +1 Approve the release -1 Do not approve the release (please explain why) This vote will be open for at least 72 hours. Best regards, David Bosschaert -- Christian Schneider http://www.liquid-reality.de Open Source Architect http://www.talend.com
