[jira] [Created] (ARIES-1414) Allow to configure code generation based on namespaces
Christian Schneider created ARIES-1414: -- Summary: Allow to configure code generation based on namespaces Key: ARIES-1414 URL: https://issues.apache.org/jira/browse/ARIES-1414 Project: Aries Issue Type: Improvement Components: Blueprint Affects Versions: blueprint-maven-plugin-1.1.0 Reporter: Christian Schneider Assignee: Christian Schneider Fix For: blueprint-maven-plugin-1.2.0 The idea is to configure the generated code by specifying the namespaces it should use. The configuration looks like this: http://aries.apache.org/xmlns/jpa/v2.0.0 http://aries.apache.org/xmlns/transactions/v2.0.0 If no namespaces are configured the two above are assumed. The list of initially supported namespaces for this config are: http://aries.apache.org/xmlns/jpa/v1.1.0 http://aries.apache.org/xmlns/jpa/v2.0.0 http://aries.apache.org/xmlns/transactions/v1.2.0 http://aries.apache.org/xmlns/transactions/v2.0.0 The 1.x namespace cause the generation of xml elements, the 2.0 namespaces just generate the respective enable elements. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (ARIES-1414) Allow to configure code generation based on namespaces
[ https://issues.apache.org/jira/browse/ARIES-1414?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schneider resolved ARIES-1414. Resolution: Fixed > Allow to configure code generation based on namespaces > -- > > Key: ARIES-1414 > URL: https://issues.apache.org/jira/browse/ARIES-1414 > Project: Aries > Issue Type: Improvement > Components: Blueprint >Affects Versions: blueprint-maven-plugin-1.1.0 > Reporter: Christian Schneider >Assignee: Christian Schneider > Fix For: blueprint-maven-plugin-1.2.0 > > > The idea is to configure the generated code by specifying the namespaces it > should use. > The configuration looks like this: > > http://aries.apache.org/xmlns/jpa/v2.0.0 > http://aries.apache.org/xmlns/transactions/v2.0.0 > > If no namespaces are configured the two above are assumed. > The list of initially supported namespaces for this config are: > http://aries.apache.org/xmlns/jpa/v1.1.0 > http://aries.apache.org/xmlns/jpa/v2.0.0 > http://aries.apache.org/xmlns/transactions/v1.2.0 > http://aries.apache.org/xmlns/transactions/v2.0.0 > The 1.x namespace cause the generation of xml elements, the 2.0 namespaces > just generate the respective enable elements. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (ARIES-1415) Exception laundering in JpaTemplate impls
[
https://issues.apache.org/jira/browse/ARIES-1415?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14902695#comment-14902695
]
Christian Schneider commented on ARIES-1415:
You are right that we should not wrap all exceptions in a RuntimeException but
I think we could do it in a simpler way:
} catch (Throwable ex) {
safeRollback(tranToken, ex);
if (ex instanceof RuntimeException) {
throw (RuntimeException) ex;
}
throw new RuntimeException(ex);
} finally {
So RuntimeException instances are simply passed to the caller. What do you
think?
> Exception laundering in JpaTemplate impls
> -
>
> Key: ARIES-1415
> URL: https://issues.apache.org/jira/browse/ARIES-1415
> Project: Aries
> Issue Type: Improvement
> Components: JPA
>Affects Versions: jpa-2.2.0
>Reporter: Matthew Pitts
>
> Currently XaJpaTemplate and ResourceLocalJpaTemplate wrap all caught
> exceptions in a new RuntimeException and throw that instead of the original.
> This can make it problematic to integrate with code that wants to run txExpr
> methods and catch specific exceptions - like NoResultException or other type
> of recoverable exception.
> Perhaps a method (like launderTxException) could be added to their base class
> - AbstractJpaTemplate - which could allow for additional exception laundering.
> Specifically, I'm thinking of something that would actually attempt to
> instantiate a new instance of the original exception type via reflection and
> populate it with the necessary detail message. If it is unable to instantiate
> the original exception, then it can simply rethrow it as-is or maintain the
> original behavior of wrapping it in a RuntimeException.
> Something like this:
> {code}
> protected RuntimeException launderTxException(Throwable original, String
> message) {
> if (RuntimeException.class.isInstance(original)) {
> return wrapTxException(RuntimeException.class.cast(original),
> message);
> }
> else {
> return new RuntimeException(message, original);
> }
> }
> protected RuntimeException wrapTxException(RuntimeException original,
> String message) {
> if (message == null)
> return original;
> try {
> RuntimeException wrapper = original.getClass().getConstructor(new
> Class[]
> { String.class }).newInstance(message);
> wrapper.initCause(original);
> return wrapper;
> }
> catch (ReflectiveOperationException e) {
> return original;
> }
> }
> {code}
> Thoughts, comments, criticisms?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (ARIES-1415) Exception laundering in JpaTemplate impls
[
https://issues.apache.org/jira/browse/ARIES-1415?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14902734#comment-14902734
]
Christian Schneider commented on ARIES-1415:
Just committed a fix. Does that work for you?
commit ffe34ef638d9c87de1d9131185706c5886dc20ff
Author: cschneider
Date: Tue Sep 22 14:40:07 2015 +
[ARIES-1415] Do not wrap RuntimeException instances
git-svn-id: https://svn.apache.org/repos/asf/aries/trunk@1704643
13f79535-47bb-0310-9956-ffa450edef68
> Exception laundering in JpaTemplate impls
> -
>
> Key: ARIES-1415
> URL: https://issues.apache.org/jira/browse/ARIES-1415
> Project: Aries
> Issue Type: Improvement
> Components: JPA
>Affects Versions: jpa-2.2.0
>Reporter: Matthew Pitts
>
> Currently XaJpaTemplate and ResourceLocalJpaTemplate wrap all caught
> exceptions in a new RuntimeException and throw that instead of the original.
> This can make it problematic to integrate with code that wants to run txExpr
> methods and catch specific exceptions - like NoResultException or other type
> of recoverable exception.
> Perhaps a method (like launderTxException) could be added to their base class
> - AbstractJpaTemplate - which could allow for additional exception laundering.
> Specifically, I'm thinking of something that would actually attempt to
> instantiate a new instance of the original exception type via reflection and
> populate it with the necessary detail message. If it is unable to instantiate
> the original exception, then it can simply rethrow it as-is or maintain the
> original behavior of wrapping it in a RuntimeException.
> Something like this:
> {code}
> protected RuntimeException launderTxException(Throwable original, String
> message) {
> if (RuntimeException.class.isInstance(original)) {
> return wrapTxException(RuntimeException.class.cast(original),
> message);
> }
> else {
> return new RuntimeException(message, original);
> }
> }
> protected RuntimeException wrapTxException(RuntimeException original,
> String message) {
> if (message == null)
> return original;
> try {
> RuntimeException wrapper = original.getClass().getConstructor(new
> Class[]
> { String.class }).newInstance(message);
> wrapper.initCause(original);
> return wrapper;
> }
> catch (ReflectiveOperationException e) {
> return original;
> }
> }
> {code}
> Thoughts, comments, criticisms?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (ARIES-1415) Exception laundering in JpaTemplate impls
[
https://issues.apache.org/jira/browse/ARIES-1415?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christian Schneider reassigned ARIES-1415:
--
Assignee: Christian Schneider
> Exception laundering in JpaTemplate impls
> -
>
> Key: ARIES-1415
> URL: https://issues.apache.org/jira/browse/ARIES-1415
> Project: Aries
> Issue Type: Improvement
> Components: JPA
>Affects Versions: jpa-2.2.0
>Reporter: Matthew Pitts
>Assignee: Christian Schneider
>
> Currently XaJpaTemplate and ResourceLocalJpaTemplate wrap all caught
> exceptions in a new RuntimeException and throw that instead of the original.
> This can make it problematic to integrate with code that wants to run txExpr
> methods and catch specific exceptions - like NoResultException or other type
> of recoverable exception.
> Perhaps a method (like launderTxException) could be added to their base class
> - AbstractJpaTemplate - which could allow for additional exception laundering.
> Specifically, I'm thinking of something that would actually attempt to
> instantiate a new instance of the original exception type via reflection and
> populate it with the necessary detail message. If it is unable to instantiate
> the original exception, then it can simply rethrow it as-is or maintain the
> original behavior of wrapping it in a RuntimeException.
> Something like this:
> {code}
> protected RuntimeException launderTxException(Throwable original, String
> message) {
> if (RuntimeException.class.isInstance(original)) {
> return wrapTxException(RuntimeException.class.cast(original),
> message);
> }
> else {
> return new RuntimeException(message, original);
> }
> }
> protected RuntimeException wrapTxException(RuntimeException original,
> String message) {
> if (message == null)
> return original;
> try {
> RuntimeException wrapper = original.getClass().getConstructor(new
> Class[]
> { String.class }).newInstance(message);
> wrapper.initCause(original);
> return wrapper;
> }
> catch (ReflectiveOperationException e) {
> return original;
> }
> }
> {code}
> Thoughts, comments, criticisms?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (ARIES-1415) Exception laundering in JpaTemplate impls
[
https://issues.apache.org/jira/browse/ARIES-1415?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14902785#comment-14902785
]
Christian Schneider commented on ARIES-1415:
I am not sure about not wrapping the exception on commit. What do you think? Do
we need the message?
I also added the wrapException in ResourceLocalJPATemplate. So that should
already work.
While checking the code I found some more small issues and committed them.
> Exception laundering in JpaTemplate impls
> -
>
> Key: ARIES-1415
> URL: https://issues.apache.org/jira/browse/ARIES-1415
> Project: Aries
> Issue Type: Improvement
> Components: JPA
>Affects Versions: jpa-2.2.0
>Reporter: Matthew Pitts
>Assignee: Christian Schneider
>
> Currently XaJpaTemplate and ResourceLocalJpaTemplate wrap all caught
> exceptions in a new RuntimeException and throw that instead of the original.
> This can make it problematic to integrate with code that wants to run txExpr
> methods and catch specific exceptions - like NoResultException or other type
> of recoverable exception.
> Perhaps a method (like launderTxException) could be added to their base class
> - AbstractJpaTemplate - which could allow for additional exception laundering.
> Specifically, I'm thinking of something that would actually attempt to
> instantiate a new instance of the original exception type via reflection and
> populate it with the necessary detail message. If it is unable to instantiate
> the original exception, then it can simply rethrow it as-is or maintain the
> original behavior of wrapping it in a RuntimeException.
> Something like this:
> {code}
> protected RuntimeException launderTxException(Throwable original, String
> message) {
> if (RuntimeException.class.isInstance(original)) {
> return wrapTxException(RuntimeException.class.cast(original),
> message);
> }
> else {
> return new RuntimeException(message, original);
> }
> }
> protected RuntimeException wrapTxException(RuntimeException original,
> String message) {
> if (message == null)
> return original;
> try {
> RuntimeException wrapper = original.getClass().getConstructor(new
> Class[]
> { String.class }).newInstance(message);
> wrapper.initCause(original);
> return wrapper;
> }
> catch (ReflectiveOperationException e) {
> return original;
> }
> }
> {code}
> Thoughts, comments, criticisms?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (ARIES-1415) Exception laundering in JpaTemplate impls
[
https://issues.apache.org/jira/browse/ARIES-1415?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14902852#comment-14902852
]
Christian Schneider commented on ARIES-1415:
I would rather avoid the reflection code. Changing an existing exception does
not seem a good idea to me. We might also have some cases where this fails.
So I will just also use wrapException for it. I will also add a message
parameter so if we wrap we can have a message. As a last change I will also
rethrow Errror instances where we catch Throwable.
> Exception laundering in JpaTemplate impls
> -
>
> Key: ARIES-1415
> URL: https://issues.apache.org/jira/browse/ARIES-1415
> Project: Aries
> Issue Type: Improvement
> Components: JPA
>Affects Versions: jpa-2.2.0
>Reporter: Matthew Pitts
>Assignee: Christian Schneider
>
> Currently XaJpaTemplate and ResourceLocalJpaTemplate wrap all caught
> exceptions in a new RuntimeException and throw that instead of the original.
> This can make it problematic to integrate with code that wants to run txExpr
> methods and catch specific exceptions - like NoResultException or other type
> of recoverable exception.
> Perhaps a method (like launderTxException) could be added to their base class
> - AbstractJpaTemplate - which could allow for additional exception laundering.
> Specifically, I'm thinking of something that would actually attempt to
> instantiate a new instance of the original exception type via reflection and
> populate it with the necessary detail message. If it is unable to instantiate
> the original exception, then it can simply rethrow it as-is or maintain the
> original behavior of wrapping it in a RuntimeException.
> Something like this:
> {code}
> protected RuntimeException launderTxException(Throwable original, String
> message) {
> if (RuntimeException.class.isInstance(original)) {
> return wrapTxException(RuntimeException.class.cast(original),
> message);
> }
> else {
> return new RuntimeException(message, original);
> }
> }
> protected RuntimeException wrapTxException(RuntimeException original,
> String message) {
> if (message == null)
> return original;
> try {
> RuntimeException wrapper = original.getClass().getConstructor(new
> Class[]
> { String.class }).newInstance(message);
> wrapper.initCause(original);
> return wrapper;
> }
> catch (ReflectiveOperationException e) {
> return original;
> }
> }
> {code}
> Thoughts, comments, criticisms?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (ARIES-1415) Exception laundering in JpaTemplate impls
[
https://issues.apache.org/jira/browse/ARIES-1415?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christian Schneider updated ARIES-1415:
---
Affects Version/s: (was: jpa-2.2.0)
jpa-2.1.0
> Exception laundering in JpaTemplate impls
> -
>
> Key: ARIES-1415
> URL: https://issues.apache.org/jira/browse/ARIES-1415
> Project: Aries
> Issue Type: Improvement
> Components: JPA
>Affects Versions: jpa-2.1.0
>Reporter: Matthew Pitts
>Assignee: Christian Schneider
> Fix For: jpa-2.2.0
>
>
> Currently XaJpaTemplate and ResourceLocalJpaTemplate wrap all caught
> exceptions in a new RuntimeException and throw that instead of the original.
> This can make it problematic to integrate with code that wants to run txExpr
> methods and catch specific exceptions - like NoResultException or other type
> of recoverable exception.
> Perhaps a method (like launderTxException) could be added to their base class
> - AbstractJpaTemplate - which could allow for additional exception laundering.
> Specifically, I'm thinking of something that would actually attempt to
> instantiate a new instance of the original exception type via reflection and
> populate it with the necessary detail message. If it is unable to instantiate
> the original exception, then it can simply rethrow it as-is or maintain the
> original behavior of wrapping it in a RuntimeException.
> Something like this:
> {code}
> protected RuntimeException launderTxException(Throwable original, String
> message) {
> if (RuntimeException.class.isInstance(original)) {
> return wrapTxException(RuntimeException.class.cast(original),
> message);
> }
> else {
> return new RuntimeException(message, original);
> }
> }
> protected RuntimeException wrapTxException(RuntimeException original,
> String message) {
> if (message == null)
> return original;
> try {
> RuntimeException wrapper = original.getClass().getConstructor(new
> Class[]
> { String.class }).newInstance(message);
> wrapper.initCause(original);
> return wrapper;
> }
> catch (ReflectiveOperationException e) {
> return original;
> }
> }
> {code}
> Thoughts, comments, criticisms?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (ARIES-1415) Exception laundering in JpaTemplate impls
[
https://issues.apache.org/jira/browse/ARIES-1415?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christian Schneider resolved ARIES-1415.
Resolution: Fixed
Fix Version/s: jpa-2.2.0
> Exception laundering in JpaTemplate impls
> -
>
> Key: ARIES-1415
> URL: https://issues.apache.org/jira/browse/ARIES-1415
> Project: Aries
> Issue Type: Improvement
> Components: JPA
>Affects Versions: jpa-2.1.0
>Reporter: Matthew Pitts
>Assignee: Christian Schneider
> Fix For: jpa-2.2.0
>
>
> Currently XaJpaTemplate and ResourceLocalJpaTemplate wrap all caught
> exceptions in a new RuntimeException and throw that instead of the original.
> This can make it problematic to integrate with code that wants to run txExpr
> methods and catch specific exceptions - like NoResultException or other type
> of recoverable exception.
> Perhaps a method (like launderTxException) could be added to their base class
> - AbstractJpaTemplate - which could allow for additional exception laundering.
> Specifically, I'm thinking of something that would actually attempt to
> instantiate a new instance of the original exception type via reflection and
> populate it with the necessary detail message. If it is unable to instantiate
> the original exception, then it can simply rethrow it as-is or maintain the
> original behavior of wrapping it in a RuntimeException.
> Something like this:
> {code}
> protected RuntimeException launderTxException(Throwable original, String
> message) {
> if (RuntimeException.class.isInstance(original)) {
> return wrapTxException(RuntimeException.class.cast(original),
> message);
> }
> else {
> return new RuntimeException(message, original);
> }
> }
> protected RuntimeException wrapTxException(RuntimeException original,
> String message) {
> if (message == null)
> return original;
> try {
> RuntimeException wrapper = original.getClass().getConstructor(new
> Class[]
> { String.class }).newInstance(message);
> wrapper.initCause(original);
> return wrapper;
> }
> catch (ReflectiveOperationException e) {
> return original;
> }
> }
> {code}
> Thoughts, comments, criticisms?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (ARIES-1415) Exception laundering in JpaTemplate impls
[
https://issues.apache.org/jira/browse/ARIES-1415?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christian Schneider updated ARIES-1415:
---
Issue Type: Bug (was: Improvement)
> Exception laundering in JpaTemplate impls
> -
>
> Key: ARIES-1415
> URL: https://issues.apache.org/jira/browse/ARIES-1415
> Project: Aries
> Issue Type: Bug
> Components: JPA
>Affects Versions: jpa-2.1.0
>Reporter: Matthew Pitts
>Assignee: Christian Schneider
> Fix For: jpa-2.2.0
>
>
> Currently XaJpaTemplate and ResourceLocalJpaTemplate wrap all caught
> exceptions in a new RuntimeException and throw that instead of the original.
> This can make it problematic to integrate with code that wants to run txExpr
> methods and catch specific exceptions - like NoResultException or other type
> of recoverable exception.
> Perhaps a method (like launderTxException) could be added to their base class
> - AbstractJpaTemplate - which could allow for additional exception laundering.
> Specifically, I'm thinking of something that would actually attempt to
> instantiate a new instance of the original exception type via reflection and
> populate it with the necessary detail message. If it is unable to instantiate
> the original exception, then it can simply rethrow it as-is or maintain the
> original behavior of wrapping it in a RuntimeException.
> Something like this:
> {code}
> protected RuntimeException launderTxException(Throwable original, String
> message) {
> if (RuntimeException.class.isInstance(original)) {
> return wrapTxException(RuntimeException.class.cast(original),
> message);
> }
> else {
> return new RuntimeException(message, original);
> }
> }
> protected RuntimeException wrapTxException(RuntimeException original,
> String message) {
> if (message == null)
> return original;
> try {
> RuntimeException wrapper = original.getClass().getConstructor(new
> Class[]
> { String.class }).newInstance(message);
> wrapper.initCause(original);
> return wrapper;
> }
> catch (ReflectiveOperationException e) {
> return original;
> }
> }
> {code}
> Thoughts, comments, criticisms?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (ARIES-1422) Support m2e incremental build in blueprint-maven-plugin
Christian Schneider created ARIES-1422: -- Summary: Support m2e incremental build in blueprint-maven-plugin Key: ARIES-1422 URL: https://issues.apache.org/jira/browse/ARIES-1422 Project: Aries Issue Type: Improvement Components: Blueprint Affects Versions: blueprint-maven-plugin-1.2.0 Reporter: Christian Schneider Assignee: Christian Schneider -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (ARIES-1422) Support m2e incremental build in blueprint-maven-plugin
[ https://issues.apache.org/jira/browse/ARIES-1422?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schneider resolved ARIES-1422. Resolution: Fixed > Support m2e incremental build in blueprint-maven-plugin > --- > > Key: ARIES-1422 > URL: https://issues.apache.org/jira/browse/ARIES-1422 > Project: Aries > Issue Type: Improvement > Components: Blueprint >Affects Versions: blueprint-maven-plugin-1.2.0 > Reporter: Christian Schneider >Assignee: Christian Schneider > Fix For: blueprint-maven-plugin-1.3.0 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (ARIES-1422) Support m2e incremental build in blueprint-maven-plugin
[ https://issues.apache.org/jira/browse/ARIES-1422?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schneider updated ARIES-1422: --- Fix Version/s: blueprint-maven-plugin-1.3.0 > Support m2e incremental build in blueprint-maven-plugin > --- > > Key: ARIES-1422 > URL: https://issues.apache.org/jira/browse/ARIES-1422 > Project: Aries > Issue Type: Improvement > Components: Blueprint >Affects Versions: blueprint-maven-plugin-1.2.0 > Reporter: Christian Schneider >Assignee: Christian Schneider > Fix For: blueprint-maven-plugin-1.3.0 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (ARIES-1430) Blueprint bundle shut down after timeout even if all dependencies are present at that time
Christian Schneider created ARIES-1430: -- Summary: Blueprint bundle shut down after timeout even if all dependencies are present at that time Key: ARIES-1430 URL: https://issues.apache.org/jira/browse/ARIES-1430 Project: Aries Issue Type: Bug Components: Blueprint Affects Versions: blueprint-core-1.4.4 Reporter: Christian Schneider Assignee: Christian Schneider Fix For: blueprint-core-1.4.5 When I run the jpa blueprint example it works fine at the start but after 4 minutes I see the exception below. When the blueprint context is created the future for the timeout of dependencies is canceled. https://github.com/apache/aries/blob/trunk/blueprint/blueprint-core/src/main/java/org/apache/aries/blueprint/container/BlueprintContainerImpl.java#L379 In Aries JPA I use a ComponentDefinitionRegistryProcessor to scan for the @PersistenceContext annoations and register a service reference for these. I think that this triggers the future for the timeout of such dependencies again. If this processor is called after the future is canceled above then the future will not be canceled anymore. So after the timeout (5min) it will trigger and stop the blueprintcontainer even if all dependencies are satisfied now. This is the code that is executed after the timeout: https://github.com/apache/aries/blob/trunk/blueprint/blueprint-core/src/main/java/org/apache/aries/blueprint/container/BlueprintContainerImpl.java#L341 It matches the exception and explains why there are no unresolved dependencies. I would be happy about feedback from anyone with deeper blueprint knowledge. Is what I do there in Aries JPA incorrect? If yes then we need a new Aries JPA release .. though I am not sure how to better address the problem. If it is correct then we need to fix this in blueprint core. A simple fix/workaround would be to check if there are no unresolved dependencies when the future times out and not stop the container in this case. A better fix would cancel the future as soon as all dependencies are fulfilled. 2015-10-11 19:08:43,371 | ERROR | rint Extender: 2 | BlueprintContainerImpl | 12 - org.apache.aries.blueprint.core - 1.4.4 | Unable to start blueprint container for bundle net.lr.tasklist.cdi.tasklist-persistence/1.0.0.SNAPSHOT due to unresolved dependencies [] java.util.concurrent.TimeoutException at org.apache.aries.blueprint.container.BlueprintContainerImpl$1.run(BlueprintContainerImpl.java:336)[12:org.apache.aries.blueprint.core:1.4.4] at org.apache.aries.blueprint.utils.threading.impl.DiscardableRunnable.run(DiscardableRunnable.java:48)[12:org.apache.aries.blueprint.core:1.4.4] at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)[:1.8.0_60] at java.util.concurrent.FutureTask.run(FutureTask.java:266)[:1.8.0_60] at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)[:1.8.0_60] at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)[:1.8.0_60] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)[:1.8.0_60] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)[:1.8.0_60] at java.lang.Thread.run(Thread.java:745)[:1.8.0_60] -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (ARIES-1430) Blueprint bundle shut down after timeout even if all dependencies are present at that time
[ https://issues.apache.org/jira/browse/ARIES-1430?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schneider updated ARIES-1430: --- Priority: Critical (was: Major) > Blueprint bundle shut down after timeout even if all dependencies are present > at that time > -- > > Key: ARIES-1430 > URL: https://issues.apache.org/jira/browse/ARIES-1430 > Project: Aries > Issue Type: Bug > Components: Blueprint >Affects Versions: blueprint-core-1.4.4 >Reporter: Christian Schneider > Assignee: Christian Schneider >Priority: Critical > Fix For: blueprint-core-1.4.5 > > > When I run the jpa blueprint example it works fine at the start but after 4 > minutes I see the exception below. > When the blueprint context is created the future for the timeout of > dependencies is canceled. > https://github.com/apache/aries/blob/trunk/blueprint/blueprint-core/src/main/java/org/apache/aries/blueprint/container/BlueprintContainerImpl.java#L379 > In Aries JPA I use a ComponentDefinitionRegistryProcessor to scan for the > @PersistenceContext annoations and register a service reference for these. I > think that this triggers > the future for the timeout of such dependencies again. If this processor is > called after the future is canceled above then the future will not be > canceled anymore. So after the timeout (5min) it will > trigger and stop the blueprintcontainer even if all dependencies are > satisfied now. > This is the code that is executed after the timeout: > https://github.com/apache/aries/blob/trunk/blueprint/blueprint-core/src/main/java/org/apache/aries/blueprint/container/BlueprintContainerImpl.java#L341 > It matches the exception and explains why there are no unresolved > dependencies. > I would be happy about feedback from anyone with deeper blueprint knowledge. > Is what I do there in Aries JPA incorrect? If yes then we need a new Aries > JPA release .. though I am not sure how to better address the problem. > If it is correct then we need to fix this in blueprint core. > A simple fix/workaround would be to check if there are no unresolved > dependencies when the future times out and not stop the container in this > case. A better fix would cancel the future as soon as all dependencies are > fulfilled. > 2015-10-11 19:08:43,371 | ERROR | rint Extender: 2 | BlueprintContainerImpl > | 12 - org.apache.aries.blueprint.core - 1.4.4 | Unable to start > blueprint container for bundle > net.lr.tasklist.cdi.tasklist-persistence/1.0.0.SNAPSHOT due to unresolved > dependencies [] > java.util.concurrent.TimeoutException > at > org.apache.aries.blueprint.container.BlueprintContainerImpl$1.run(BlueprintContainerImpl.java:336)[12:org.apache.aries.blueprint.core:1.4.4] > at > org.apache.aries.blueprint.utils.threading.impl.DiscardableRunnable.run(DiscardableRunnable.java:48)[12:org.apache.aries.blueprint.core:1.4.4] > at > java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)[:1.8.0_60] > at java.util.concurrent.FutureTask.run(FutureTask.java:266)[:1.8.0_60] > at > java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)[:1.8.0_60] > at > java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)[:1.8.0_60] > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)[:1.8.0_60] > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)[:1.8.0_60] > at java.lang.Thread.run(Thread.java:745)[:1.8.0_60] -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (ARIES-1430) Blueprint bundle shut down after timeout even if all dependencies are present at that time
[ https://issues.apache.org/jira/browse/ARIES-1430?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schneider resolved ARIES-1430. Resolution: Fixed Resolved with a workaround .. we should discuss a better solution though > Blueprint bundle shut down after timeout even if all dependencies are present > at that time > -- > > Key: ARIES-1430 > URL: https://issues.apache.org/jira/browse/ARIES-1430 > Project: Aries > Issue Type: Bug > Components: Blueprint >Affects Versions: blueprint-core-1.4.4 >Reporter: Christian Schneider > Assignee: Christian Schneider >Priority: Critical > Fix For: blueprint-core-1.4.5 > > > When I run the jpa blueprint example it works fine at the start but after 4 > minutes I see the exception below. > When the blueprint context is created the future for the timeout of > dependencies is canceled. > https://github.com/apache/aries/blob/trunk/blueprint/blueprint-core/src/main/java/org/apache/aries/blueprint/container/BlueprintContainerImpl.java#L379 > In Aries JPA I use a ComponentDefinitionRegistryProcessor to scan for the > @PersistenceContext annoations and register a service reference for these. I > think that this triggers > the future for the timeout of such dependencies again. If this processor is > called after the future is canceled above then the future will not be > canceled anymore. So after the timeout (5min) it will > trigger and stop the blueprintcontainer even if all dependencies are > satisfied now. > This is the code that is executed after the timeout: > https://github.com/apache/aries/blob/trunk/blueprint/blueprint-core/src/main/java/org/apache/aries/blueprint/container/BlueprintContainerImpl.java#L341 > It matches the exception and explains why there are no unresolved > dependencies. > I would be happy about feedback from anyone with deeper blueprint knowledge. > Is what I do there in Aries JPA incorrect? If yes then we need a new Aries > JPA release .. though I am not sure how to better address the problem. > If it is correct then we need to fix this in blueprint core. > A simple fix/workaround would be to check if there are no unresolved > dependencies when the future times out and not stop the container in this > case. A better fix would cancel the future as soon as all dependencies are > fulfilled. > 2015-10-11 19:08:43,371 | ERROR | rint Extender: 2 | BlueprintContainerImpl > | 12 - org.apache.aries.blueprint.core - 1.4.4 | Unable to start > blueprint container for bundle > net.lr.tasklist.cdi.tasklist-persistence/1.0.0.SNAPSHOT due to unresolved > dependencies [] > java.util.concurrent.TimeoutException > at > org.apache.aries.blueprint.container.BlueprintContainerImpl$1.run(BlueprintContainerImpl.java:336)[12:org.apache.aries.blueprint.core:1.4.4] > at > org.apache.aries.blueprint.utils.threading.impl.DiscardableRunnable.run(DiscardableRunnable.java:48)[12:org.apache.aries.blueprint.core:1.4.4] > at > java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)[:1.8.0_60] > at java.util.concurrent.FutureTask.run(FutureTask.java:266)[:1.8.0_60] > at > java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)[:1.8.0_60] > at > java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)[:1.8.0_60] > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)[:1.8.0_60] > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)[:1.8.0_60] > at java.lang.Thread.run(Thread.java:745)[:1.8.0_60] -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (ARIES-1432) EMFTracker getTransactionType() method always returns PersistenceUnitTransactionType.JTA
[ https://issues.apache.org/jira/browse/ARIES-1432?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14957901#comment-14957901 ] Christian Schneider commented on ARIES-1432: The transaction type should be set in org.apache.aries.jpa.container.impl.ManagedEMF. I see that it is set there but I am sure it is really used. Maybe this got lost in the change to support overriding properties using config admin. So if you want to take a look at it that would be great. Btw. I wonder how much RESOURCE_LOCAL is really needed. I kept it as it was there before but the spec says that inside a container you should always use JTA. So I wonder if we should maybe remove the support. > EMFTracker getTransactionType() method always returns > PersistenceUnitTransactionType.JTA > > > Key: ARIES-1432 > URL: https://issues.apache.org/jira/browse/ARIES-1432 > Project: Aries > Issue Type: Bug > Components: JPA >Affects Versions: jpa-2.1.0, jpa-2.3.0 >Reporter: Tim >Priority: Minor > > It looks as though the EMFTracker getTransactionType() method is not working > correctly, it always returns a PersistenceUnitTransactionType.JTA regardless > of the transaction-type (JTA or RESOURCE_LOCAL). Consequently the > ResourceLocalJpaTemplate is never instantiated if RESOURCE_LOCAL is specified > in the persistence.xml. > I could probably help if I knew where/why the logic for retrieving the > PersistenceUnitTransactionType from the properties of the > EntityManagerFactory came from? > The bundles I installed were > feature:install scr > feature:install jpa/2.1.0 > feature:install hibernate/4.3.6.Final > feature:repo-add mvn:org.ops4j.pax.jdbc/pax-jdbc-features/0.7.0/xml/features > feature:install pax-jdbc-h2 > feature:install transaction > feature:install pax-jdbc-pool-dbcp2 > feature:install pax-jdbc-config > service:list javax.sql.DataSource > bundle:install -s mvn:net.lr.tasklist.ds/tasklist-model/1.0.0-SNAPSHOT > bundle:install -s mvn:net.lr.tasklist.ds/tasklist-persistence/1.0.0-SNAPSHOT > feature:install http-whiteboard > feature:install persistence-api > bundle:install -s mvn:net.lr.tasklist.ds/tasklist-ui/1.0.0-SNAPSHOT > with a config > osgi.jdbc.driver.name=H2-pool > url=jdbc:h2:mem:test > user=sa > password= > dataSourceName=tasklist > 1) If the transaction-type="JTA" in persistence.xml (even though > osgi.jdbc.driver.name=H2-pool) the tasklist tests will appear to work e.g. > another task can be saved. However I modified the test to insert 2 tasks > within one lambda expression and throw a Runtime exception after the first > task insertion, expected result would be that the first insertion is rolled > back, however it was committed. > 2) If the transaction-type="RESOURCE_LOCAL" in persistence.xml the following > exception is thrown (note the presence of XAJpaTemplate rather than > ResourceLocalJpaTemplate) > java.lang.RuntimeException: java.lang.RuntimeException: > javax.persistence.TransactionRequiredException: no transaction is in progress > at > org.apache.aries.jpa.support.impl.XAJpaTemplate.txExpr(XAJpaTemplate.java:62) > at > org.apache.aries.jpa.support.impl.AbstractJpaTemplate.tx(AbstractJpaTemplate.java:32) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (ARIES-1433) Persistence units are not picked up while bundle is in status resolved
Christian Schneider created ARIES-1433: -- Summary: Persistence units are not picked up while bundle is in status resolved Key: ARIES-1433 URL: https://issues.apache.org/jira/browse/ARIES-1433 Project: Aries Issue Type: Bug Components: JPA Affects Versions: jpa-2.2.0 Reporter: Christian Schneider Assignee: Christian Schneider Fix For: jpa-2.3.0 Currently the PersistenceBundleTracker only watches bundle in state Bundle.STARTING | Bundle.ACTIVE. So if you put a persistence unit definition and a blueprint JPA bean using the persistence unit into the same bundle then it will never start. We should also track bundles in state resolved. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (ARIES-1322) Introduce Namespaces annotation
[ https://issues.apache.org/jira/browse/ARIES-1322?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schneider updated ARIES-1322: --- Fix Version/s: (was: blueprint-parser-1.1.1) blueprint-parser-1.1.0 > Introduce Namespaces annotation > --- > > Key: ARIES-1322 > URL: https://issues.apache.org/jira/browse/ARIES-1322 > Project: Aries > Issue Type: Improvement > Components: Blueprint >Reporter: Sergey Beryozkin >Assignee: Sergey Beryozkin >Priority: Minor > Fix For: blueprint-parser-1.1.1 > > > This applies to a blueprint-parser component. > NamespaceHandler interface does not list the namespaces this handler supports > which makes it difficult to automate the registration of handlers in non-OSGI > contexts. > Having a Namespace annotation will provide an optional mechanism for > NamespaceHandlers to advertise the list of supported namespaces and help > discovering the handlers in non OSGI contexts but also introspect them in > OSGI if needed. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (ARIES-1322) Introduce Namespaces annotation
[ https://issues.apache.org/jira/browse/ARIES-1322?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schneider updated ARIES-1322: --- Fix Version/s: (was: blueprint-parser-1.1.0) blueprint-parser-1.1.1 > Introduce Namespaces annotation > --- > > Key: ARIES-1322 > URL: https://issues.apache.org/jira/browse/ARIES-1322 > Project: Aries > Issue Type: Improvement > Components: Blueprint >Reporter: Sergey Beryozkin >Assignee: Sergey Beryozkin >Priority: Minor > Fix For: blueprint-parser-1.1.1 > > > This applies to a blueprint-parser component. > NamespaceHandler interface does not list the namespaces this handler supports > which makes it difficult to automate the registration of handlers in non-OSGI > contexts. > Having a Namespace annotation will provide an optional mechanism for > NamespaceHandlers to advertise the list of supported namespaces and help > discovering the handlers in non OSGI contexts but also introspect them in > OSGI if needed. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (ARIES-1353) NullpointerException when trying to log an exception
[
https://issues.apache.org/jira/browse/ARIES-1353?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christian Schneider resolved ARIES-1353.
Resolution: Fixed
Assignee: Christian Schneider
> NullpointerException when trying to log an exception
>
>
> Key: ARIES-1353
> URL: https://issues.apache.org/jira/browse/ARIES-1353
> Project: Aries
> Issue Type: Bug
> Components: Blueprint
>Affects Versions: blueprint-core-1.4.3
>Reporter: Jürgen Kindler
>Assignee: Christian Schneider
> Fix For: blueprint-core-1.4.5
>
>
> During installation of a feature in Karaf, I get the following exception in
> blueprint core 1.4.3:
> {panel}
> Caused by: java.lang.NullPointerException
> at
> org.apache.aries.blueprint.container.BeanRecipe.getInstance(BeanRecipe.java:300)[15:org.apache.aries.blueprint.core:1.4.3]
> at
> org.apache.aries.blueprint.container.BeanRecipe.internalCreate2(BeanRecipe.java:806)[15:org.apache.aries.blueprint.core:1.4.3]
> at
> org.apache.aries.blueprint.container.BeanRecipe.internalCreate(BeanRecipe.java:787)[15:org.apache.aries.blueprint.core:1.4.3]
> at
> org.apache.aries.blueprint.di.AbstractRecipe$1.call(AbstractRecipe.java:79)[15:org.apache.aries.blueprint.core:1.4.3]
> at java.util.concurrent.FutureTask.run(FutureTask.java:262)[:1.7.0_67]
> at
> org.apache.aries.blueprint.di.AbstractRecipe.create(AbstractRecipe.java:88)[15:org.apache.aries.blueprint.core:1.4.3]
> at
> org.apache.aries.blueprint.di.RefRecipe.internalCreate(RefRecipe.java:62)[15:org.apache.aries.blueprint.core:1.4.3]
> at
> org.apache.aries.blueprint.di.AbstractRecipe.create(AbstractRecipe.java:106)[15:org.apache.aries.blueprint.core:1.4.3]
> at
> org.apache.aries.blueprint.container.ServiceRecipe.createService(ServiceRecipe.java:284)[15:org.apache.aries.blueprint.core:1.4.3]
> ... 38 more
> {panel}
> Looks like when logging the exception in the exception handler getType()
> returns null :
> {code}
> try {
> Map.Entry> match =
> matches.entrySet().iterator().next();
> instance = invoke(match.getKey(), factoryObj,
> match.getValue().toArray());
> } catch (Throwable e) {
> /* line 300! */ throw new
> ComponentDefinitionException("Error when instantiating bean " + getName() + "
> of class " + getType().getName(), getRealCause(e));
> }
> {code}
> So it is not clear what the real reason for the problem is ... :-(
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (ARIES-1433) Persistence units are not picked up while bundle is in status resolved
[ https://issues.apache.org/jira/browse/ARIES-1433?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14971037#comment-14971037 ] Christian Schneider commented on ARIES-1433: I am not sure if we can make this work at all. When the persistence unit is processed we would like to register a service for the EMF on behalf of the bundle. This is only possible for bundles in state Active as far as I know. > Persistence units are not picked up while bundle is in status resolved > -- > > Key: ARIES-1433 > URL: https://issues.apache.org/jira/browse/ARIES-1433 > Project: Aries > Issue Type: Bug > Components: JPA >Affects Versions: jpa-2.2.0 > Reporter: Christian Schneider >Assignee: Christian Schneider > Fix For: jpa-2.3.0 > > > Currently the PersistenceBundleTracker only watches bundle in state > Bundle.STARTING | Bundle.ACTIVE. > So if you put a persistence unit definition and a blueprint JPA bean using > the persistence unit into the same bundle then it will never start. > We should also track bundles in state resolved. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (ARIES-1438) NPE in XAJpaTemplate#txExpr if Coordinator is null
[
https://issues.apache.org/jira/browse/ARIES-1438?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christian Schneider reassigned ARIES-1438:
--
Assignee: Christian Schneider
> NPE in XAJpaTemplate#txExpr if Coordinator is null
> --
>
> Key: ARIES-1438
> URL: https://issues.apache.org/jira/browse/ARIES-1438
> Project: Aries
> Issue Type: Bug
> Components: JPA
>Affects Versions: jpa-2.2.0
>Reporter: Matthew Pitts
>Assignee: Christian Schneider
> Fix For: jpa-2.3.0
>
>
> XAJpaTemplate uses the following code to initialize the transaction and later
> calls Coordinator#end in a finally block.
> {code:java}
> TransactionAttribute ta = TransactionAttribute.fromType(type);
> Coordination coord = null;
> try {
> tranToken = ta.begin(tm);
> coord = coordinator.begin(this.getClass().getName(), 0);
> {code}
> However, if the call to _ta.begin(tm)_ fails, then the _coord_ reference will
> be null, thus provoking an NPE during the finally block. This will then
> suppress the original exception that prevented _ta.begin_ from succeeding.
> A null-check on _coord_ prior to the invocation of Coordinator#end should
> suffice to fix this, but perhaps there's another problem here.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (ARIES-1438) NPE in XAJpaTemplate#txExpr if Coordinator is null
[
https://issues.apache.org/jira/browse/ARIES-1438?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christian Schneider updated ARIES-1438:
---
Fix Version/s: jpa-2.3.0
> NPE in XAJpaTemplate#txExpr if Coordinator is null
> --
>
> Key: ARIES-1438
> URL: https://issues.apache.org/jira/browse/ARIES-1438
> Project: Aries
> Issue Type: Bug
> Components: JPA
>Affects Versions: jpa-2.2.0
>Reporter: Matthew Pitts
>Assignee: Christian Schneider
> Fix For: jpa-2.3.0
>
>
> XAJpaTemplate uses the following code to initialize the transaction and later
> calls Coordinator#end in a finally block.
> {code:java}
> TransactionAttribute ta = TransactionAttribute.fromType(type);
> Coordination coord = null;
> try {
> tranToken = ta.begin(tm);
> coord = coordinator.begin(this.getClass().getName(), 0);
> {code}
> However, if the call to _ta.begin(tm)_ fails, then the _coord_ reference will
> be null, thus provoking an NPE during the finally block. This will then
> suppress the original exception that prevented _ta.begin_ from succeeding.
> A null-check on _coord_ prior to the invocation of Coordinator#end should
> suffice to fix this, but perhaps there's another problem here.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (ARIES-1438) NPE in XAJpaTemplate#txExpr if Coordinator is null
[
https://issues.apache.org/jira/browse/ARIES-1438?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14976302#comment-14976302
]
Christian Schneider commented on ARIES-1438:
Sounds like a valid bug. Do you want to supply a patch or should I just fix it?
> NPE in XAJpaTemplate#txExpr if Coordinator is null
> --
>
> Key: ARIES-1438
> URL: https://issues.apache.org/jira/browse/ARIES-1438
> Project: Aries
> Issue Type: Bug
> Components: JPA
>Affects Versions: jpa-2.2.0
>Reporter: Matthew Pitts
> Fix For: jpa-2.3.0
>
>
> XAJpaTemplate uses the following code to initialize the transaction and later
> calls Coordinator#end in a finally block.
> {code:java}
> TransactionAttribute ta = TransactionAttribute.fromType(type);
> Coordination coord = null;
> try {
> tranToken = ta.begin(tm);
> coord = coordinator.begin(this.getClass().getName(), 0);
> {code}
> However, if the call to _ta.begin(tm)_ fails, then the _coord_ reference will
> be null, thus provoking an NPE during the finally block. This will then
> suppress the original exception that prevented _ta.begin_ from succeeding.
> A null-check on _coord_ prior to the invocation of Coordinator#end should
> suffice to fix this, but perhaps there's another problem here.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (ARIES-1438) NPE in XAJpaTemplate#txExpr if Coordinator is null
[
https://issues.apache.org/jira/browse/ARIES-1438?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christian Schneider resolved ARIES-1438.
Resolution: Fixed
commit 1b027d2795d702bb7fc076b6a4790c2f2ddcce7f
Author: Christian Schneider
Date: Tue Oct 27 15:06:35 2015 +0100
[ARIES-1438] Fixed NPE with thanks to Matthew Pitts
> NPE in XAJpaTemplate#txExpr if Coordinator is null
> --
>
> Key: ARIES-1438
> URL: https://issues.apache.org/jira/browse/ARIES-1438
> Project: Aries
> Issue Type: Bug
> Components: JPA
>Affects Versions: jpa-2.2.0
>Reporter: Matthew Pitts
>Assignee: Christian Schneider
> Fix For: jpa-2.3.0
>
> Attachments: org.apache.aries.jpa.support.patch
>
>
> XAJpaTemplate uses the following code to initialize the transaction and later
> calls Coordinator#end in a finally block.
> {code:java}
> TransactionAttribute ta = TransactionAttribute.fromType(type);
> Coordination coord = null;
> try {
> tranToken = ta.begin(tm);
> coord = coordinator.begin(this.getClass().getName(), 0);
> {code}
> However, if the call to _ta.begin(tm)_ fails, then the _coord_ reference will
> be null, thus provoking an NPE during the finally block. This will then
> suppress the original exception that prevented _ta.begin_ from succeeding.
> A null-check on _coord_ prior to the invocation of Coordinator#end should
> suffice to fix this, but perhaps there's another problem here.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (ARIES-1447) JPAWeavingHook transforming with wrong classloader
[
https://issues.apache.org/jira/browse/ARIES-1447?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14985238#comment-14985238
]
Christian Schneider commented on ARIES-1447:
Can you post the problem you get with the current approach? In the itests it
seems that the enhancement works.
> JPAWeavingHook transforming with wrong classloader
> --
>
> Key: ARIES-1447
> URL: https://issues.apache.org/jira/browse/ARIES-1447
> Project: Aries
> Issue Type: Bug
> Components: JPA
>Affects Versions: jpa-2.2.0
> Environment: jpa 1.0.1
>Reporter: Tuomas Kiviaho
>
> {{PersistenceUnitInfo}} has a {{getNewTempClassLoader}} which includes both
> provider and persistence unit classloader. The provider classloader is
> important when enhancing the class, but now the transformations is only done
> against persistence unit classloader that doesn't yet have needed the dynamic
> imports in place.
> As a workaround, I am mimicking the proper approach by using
> {{TempBundleDelegatingClassLoader}} in my patched version of
> {{WrappingTransformer}}
> BTW: The {{org.apache.aries.jpa.container.weaving.packages}} (that seems to
> be completely removed from 2.x???) could be replaced with ASM code that looks
> for referenced packages before and after transformation and adds the
> difference to dynamic imports. How I'm adding packages manually because the
> wildcard approach just doesn't seem right.
> {code:title=org/apache/aries/jpa/container/weaving/impl/WrappingTransformer.java
> }
> @@ -26,7 +26,9 @@
> import javax.persistence.spi.ClassTransformer;
>
> import org.apache.aries.jpa.container.impl.NLS;
> +import
> org.apache.aries.jpa.container.unit.impl.TempBundleDelegatingClassLoader;
> import org.osgi.framework.Bundle;
> +import org.osgi.framework.BundleReference;
> import org.osgi.framework.Constants;
> import org.osgi.framework.ServiceReference;
> import org.osgi.framework.wiring.BundleCapability;
> @@ -35,6 +37,7 @@
>
> class WrappingTransformer implements ClassTransformer {
>private final ClassTransformer delegate;
> + private final ServiceReference persistenceProvider;
>private final Collection packageImportsToAdd = new
> HashSet();
>
>public WrappingTransformer(ClassTransformer delegate,
> @@ -48,6 +51,7 @@
> }
>
> this.delegate = delegate;
> +this.persistenceProvider = persistenceProvider;
>
> Object packages =
> persistenceProvider.getProperty("org.apache.aries.jpa.container.weaving.packages");
>
> @@ -56,7 +60,7 @@
> packageImportsToAdd.add(s);
>}
> } else {
> - Bundle provider = persistenceProvider.getBundle();
> + Bundle provider = persistenceProvider.getBundle();
>String suffix = ";" + Constants.BUNDLE_SYMBOLICNAME_ATTRIBUTE + "=" +
>provider.getSymbolicName() + ";" + Constants.BUNDLE_VERSION_ATTRIBUTE
>+ "=" + provider.getVersion();
> @@ -70,11 +74,25 @@
>
>public WrappingTransformer(ClassTransformer transformer) {
> delegate = transformer;
> +persistenceProvider = null;
>}
>
>public byte[] transform(ClassLoader arg0, String arg1, Class arg2,
>ProtectionDomain arg3, byte[] arg4) throws IllegalClassFormatException
> {
> -return delegate.transform(arg0, arg1, arg2, arg3, arg4);
> +Bundle bundle = this.persistenceProvider.getBundle();
> +BundleWiring bundleWiring = bundle.adapt(BundleWiring.class);
> +ClassLoader classLoader = bundleWiring.getClassLoader();
> +BundleReference bundleReference = (BundleReference) arg0;
> +bundle = bundleReference.getBundle();
> +classLoader = new TempBundleDelegatingClassLoader(bundle, classLoader);
> +Thread thread = Thread.currentThread();
> +ClassLoader contextClassLoader = thread.getContextClassLoader();
> +thread.setContextClassLoader(classLoader);
> +try {
> + return delegate.transform(classLoader, arg1, arg2, arg3, arg4);
> +} finally {
> + thread.setContextClassLoader(contextClassLoader);
> +}
>}
>
>public Collection getPackagesToAdd() {
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (ARIES-1430) Blueprint bundle shut down after timeout even if all dependencies are present at that time
[ https://issues.apache.org/jira/browse/ARIES-1430?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14998580#comment-14998580 ] Christian Schneider commented on ARIES-1430: That is possible. I only assumed that the problem is related to the fact that service dependencies are added late. I am not aware of any NameSpaceHandler that is unregistered in my case. Interestingly the problem only seemed to happen with the newest Aries JPA. In any case the fix I did should not cause harm but the correct solution is probably rather to make sure the timer is canceled when all deps are found. > Blueprint bundle shut down after timeout even if all dependencies are present > at that time > -- > > Key: ARIES-1430 > URL: https://issues.apache.org/jira/browse/ARIES-1430 > Project: Aries > Issue Type: Bug > Components: Blueprint >Affects Versions: blueprint-core-1.4.4 >Reporter: Christian Schneider > Assignee: Christian Schneider >Priority: Critical > Fix For: blueprint-core-1.4.5 > > > When I run the jpa blueprint example it works fine at the start but after 4 > minutes I see the exception below. > When the blueprint context is created the future for the timeout of > dependencies is canceled. > https://github.com/apache/aries/blob/trunk/blueprint/blueprint-core/src/main/java/org/apache/aries/blueprint/container/BlueprintContainerImpl.java#L379 > In Aries JPA I use a ComponentDefinitionRegistryProcessor to scan for the > @PersistenceContext annoations and register a service reference for these. I > think that this triggers > the future for the timeout of such dependencies again. If this processor is > called after the future is canceled above then the future will not be > canceled anymore. So after the timeout (5min) it will > trigger and stop the blueprintcontainer even if all dependencies are > satisfied now. > This is the code that is executed after the timeout: > https://github.com/apache/aries/blob/trunk/blueprint/blueprint-core/src/main/java/org/apache/aries/blueprint/container/BlueprintContainerImpl.java#L341 > It matches the exception and explains why there are no unresolved > dependencies. > I would be happy about feedback from anyone with deeper blueprint knowledge. > Is what I do there in Aries JPA incorrect? If yes then we need a new Aries > JPA release .. though I am not sure how to better address the problem. > If it is correct then we need to fix this in blueprint core. > A simple fix/workaround would be to check if there are no unresolved > dependencies when the future times out and not stop the container in this > case. A better fix would cancel the future as soon as all dependencies are > fulfilled. > 2015-10-11 19:08:43,371 | ERROR | rint Extender: 2 | BlueprintContainerImpl > | 12 - org.apache.aries.blueprint.core - 1.4.4 | Unable to start > blueprint container for bundle > net.lr.tasklist.cdi.tasklist-persistence/1.0.0.SNAPSHOT due to unresolved > dependencies [] > java.util.concurrent.TimeoutException > at > org.apache.aries.blueprint.container.BlueprintContainerImpl$1.run(BlueprintContainerImpl.java:336)[12:org.apache.aries.blueprint.core:1.4.4] > at > org.apache.aries.blueprint.utils.threading.impl.DiscardableRunnable.run(DiscardableRunnable.java:48)[12:org.apache.aries.blueprint.core:1.4.4] > at > java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)[:1.8.0_60] > at java.util.concurrent.FutureTask.run(FutureTask.java:266)[:1.8.0_60] > at > java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)[:1.8.0_60] > at > java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)[:1.8.0_60] > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)[:1.8.0_60] > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)[:1.8.0_60] > at java.lang.Thread.run(Thread.java:745)[:1.8.0_60] -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (ARIES-1448) Fix Issues reported by Sonar
Christian Schneider created ARIES-1448: -- Summary: Fix Issues reported by Sonar Key: ARIES-1448 URL: https://issues.apache.org/jira/browse/ARIES-1448 Project: Aries Issue Type: Improvement Components: JPA Affects Versions: jpa-2.2.0 Reporter: Christian Schneider Assignee: Christian Schneider Fix For: jpa-2.3.0 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (ARIES-1450) Cache computation of effective txType
Christian Schneider created ARIES-1450: -- Summary: Cache computation of effective txType Key: ARIES-1450 URL: https://issues.apache.org/jira/browse/ARIES-1450 Project: Aries Issue Type: Improvement Components: Transaction Affects Versions: transaction-blueprint-2.0.0 Reporter: Christian Schneider Assignee: Christian Schneider Fix For: transaction-3.0.0 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (ARIES-1450) Cache computation of effective txType
[ https://issues.apache.org/jira/browse/ARIES-1450?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schneider resolved ARIES-1450. Resolution: Fixed > Cache computation of effective txType > - > > Key: ARIES-1450 > URL: https://issues.apache.org/jira/browse/ARIES-1450 > Project: Aries > Issue Type: Improvement > Components: Transaction >Affects Versions: transaction-blueprint-2.0.0 > Reporter: Christian Schneider >Assignee: Christian Schneider > Fix For: transaction-3.0.0 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (ARIES-1448) Fix Issues reported by Sonar
[ https://issues.apache.org/jira/browse/ARIES-1448?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schneider resolved ARIES-1448. Resolution: Fixed > Fix Issues reported by Sonar > > > Key: ARIES-1448 > URL: https://issues.apache.org/jira/browse/ARIES-1448 > Project: Aries > Issue Type: Improvement > Components: JPA >Affects Versions: jpa-2.2.0 > Reporter: Christian Schneider >Assignee: Christian Schneider > Fix For: jpa-2.3.0 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (ARIES-1447) JPAWeavingHook transforming with wrong classloader
[
https://issues.apache.org/jira/browse/ARIES-1447?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15006708#comment-15006708
]
Christian Schneider commented on ARIES-1447:
The current code for enhancement is not really complete. I just did the minimal
work on it as I am not sure the current model where an EntityManager is needed
to do the enhancement really makes sense for OSGi. I would prefer a solution
that can happen at an earlier state and where the persistence provider can
communicate what packages it needs to do the enhancement. Eventually this could
be a theme for a new OSGi JPA spec. Alternatively the providers could do the
enhancement themselves as they know best what they need. I am willing to help
in any case.
For the current code it of course makes sense to fix it for hibernate 5. As I
was not able to look deeper into the new hibernate I would be happy for some
help with this.
> JPAWeavingHook transforming with wrong classloader
> --
>
> Key: ARIES-1447
> URL: https://issues.apache.org/jira/browse/ARIES-1447
> Project: Aries
> Issue Type: Bug
> Components: JPA
>Affects Versions: jpa-2.2.0
> Environment: jpa 1.0.1
>Reporter: Tuomas Kiviaho
>
> {{PersistenceUnitInfo}} has a {{getNewTempClassLoader}} which includes both
> provider and persistence unit classloader. The provider classloader is
> important when enhancing the class, but now the transformations is only done
> against persistence unit classloader that doesn't yet have needed the dynamic
> imports in place.
> As a workaround, I am mimicking the proper approach by using
> {{TempBundleDelegatingClassLoader}} in my patched version of
> {{WrappingTransformer}}
> BTW: The {{org.apache.aries.jpa.container.weaving.packages}} (that seems to
> be completely removed from 2.x???) could be replaced with ASM code that looks
> for referenced packages before and after transformation and adds the
> difference to dynamic imports. How I'm adding packages manually because the
> wildcard approach just doesn't seem right.
> {code:title=org/apache/aries/jpa/container/weaving/impl/WrappingTransformer.java
> }
> @@ -26,7 +26,9 @@
> import javax.persistence.spi.ClassTransformer;
>
> import org.apache.aries.jpa.container.impl.NLS;
> +import
> org.apache.aries.jpa.container.unit.impl.TempBundleDelegatingClassLoader;
> import org.osgi.framework.Bundle;
> +import org.osgi.framework.BundleReference;
> import org.osgi.framework.Constants;
> import org.osgi.framework.ServiceReference;
> import org.osgi.framework.wiring.BundleCapability;
> @@ -35,6 +37,7 @@
>
> class WrappingTransformer implements ClassTransformer {
>private final ClassTransformer delegate;
> + private final ServiceReference persistenceProvider;
>private final Collection packageImportsToAdd = new
> HashSet();
>
>public WrappingTransformer(ClassTransformer delegate,
> @@ -48,6 +51,7 @@
> }
>
> this.delegate = delegate;
> +this.persistenceProvider = persistenceProvider;
>
> Object packages =
> persistenceProvider.getProperty("org.apache.aries.jpa.container.weaving.packages");
>
> @@ -56,7 +60,7 @@
> packageImportsToAdd.add(s);
>}
> } else {
> - Bundle provider = persistenceProvider.getBundle();
> + Bundle provider = persistenceProvider.getBundle();
>String suffix = ";" + Constants.BUNDLE_SYMBOLICNAME_ATTRIBUTE + "=" +
>provider.getSymbolicName() + ";" + Constants.BUNDLE_VERSION_ATTRIBUTE
>+ "=" + provider.getVersion();
> @@ -70,11 +74,25 @@
>
>public WrappingTransformer(ClassTransformer transformer) {
> delegate = transformer;
> +persistenceProvider = null;
>}
>
>public byte[] transform(ClassLoader arg0, String arg1, Class arg2,
>ProtectionDomain arg3, byte[] arg4) throws IllegalClassFormatException
> {
> -return delegate.transform(arg0, arg1, arg2, arg3, arg4);
> +Bundle bundle = this.persistenceProvider.getBundle();
> +BundleWiring bundleWiring = bundle.adapt(BundleWiring.class);
> +ClassLoader classLoader = bundleWiring.getClassLoader();
> +BundleReference bundleReference = (BundleReference) arg0;
> +bundle = bundleReference.getBundle();
> +classLoader = new TempBundleDelegatingClassLoader(bundle, classLoader);
> +Thread thread = Thread.currentThread();
> +ClassLoader contextClassLoader = thread.getContextClassLoader();
> +thread.setContextClassLoader(classLoader);
> +try {
> + return delegate.transform(classLoader, arg1, arg2, arg3, arg4);
> +} finally {
> + thread.setContextClassLoader(contextClassLoader);
> +}
>}
>
>public Collection getPackagesToAdd() {
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (ARIES-1454) NPE in TxInterceptor
[
https://issues.apache.org/jira/browse/ARIES-1454?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christian Schneider updated ARIES-1454:
---
Fix Version/s: transaction-3.0.0
> NPE in TxInterceptor
>
>
> Key: ARIES-1454
> URL: https://issues.apache.org/jira/browse/ARIES-1454
> Project: Aries
> Issue Type: Bug
> Components: Transaction
>Affects Versions: transaction-blueprint-1.1.1
> Environment: Karaf 4.0.2 (Felix)
> JPA (Hibernate)
>Reporter: Mohammad Shamsi
> Fix For: transaction-3.0.0
>
>
> I am running some load tests agains an osgi app, which is running inside
> karaf 4.0.2, using Aries Blueprint and JPA (Hibernate) .
> The test is using multiple threads (10) to issue some random calls to the
> application.
> Sometimes, randomly, some of the call throwing NPE in TxInterceptor:
> {code:java}
> java.lang.NullPointerException
> at
> org.apache.aries.transaction.TxInterceptorImpl.postCallWithReturn(TxInterceptorImpl.java:101)[66:org.apache.aries.transaction.blueprint:1.1.1]
> at
> org.apache.aries.blueprint.proxy.SingleInterceptorCollaborator.postInvoke(SingleInterceptorCollaborator.java:75)[48:org.apache.aries.blueprint.core:1.4.4]
> at Proxy65968de8_a064_4203_9a53_5f0c8e536279.lockAll(Unknown
> Source)[:]
> {code}
> The NPE is thrown from "postCallWithReturn" and "postCallWithException" in
> following line:
> {code:java}
> token.getCoordination().end();
> {code}
> The "getCoordination()" call in above line is returning null.
> As I mentioned, it is happening from time to time. sometimes after 20 mins,
> sometimes after hours of test execution and it is happening in different
> transactional methods in different classes of the application.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (ARIES-1454) NPE in TxInterceptor
[
https://issues.apache.org/jira/browse/ARIES-1454?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christian Schneider reassigned ARIES-1454:
--
Assignee: Christian Schneider
> NPE in TxInterceptor
>
>
> Key: ARIES-1454
> URL: https://issues.apache.org/jira/browse/ARIES-1454
> Project: Aries
> Issue Type: Bug
> Components: Transaction
>Affects Versions: transaction-blueprint-1.1.1
> Environment: Karaf 4.0.2 (Felix)
> JPA (Hibernate)
>Reporter: Mohammad Shamsi
> Assignee: Christian Schneider
> Fix For: transaction-3.0.0
>
>
> I am running some load tests agains an osgi app, which is running inside
> karaf 4.0.2, using Aries Blueprint and JPA (Hibernate) .
> The test is using multiple threads (10) to issue some random calls to the
> application.
> Sometimes, randomly, some of the call throwing NPE in TxInterceptor:
> {code:java}
> java.lang.NullPointerException
> at
> org.apache.aries.transaction.TxInterceptorImpl.postCallWithReturn(TxInterceptorImpl.java:101)[66:org.apache.aries.transaction.blueprint:1.1.1]
> at
> org.apache.aries.blueprint.proxy.SingleInterceptorCollaborator.postInvoke(SingleInterceptorCollaborator.java:75)[48:org.apache.aries.blueprint.core:1.4.4]
> at Proxy65968de8_a064_4203_9a53_5f0c8e536279.lockAll(Unknown
> Source)[:]
> {code}
> The NPE is thrown from "postCallWithReturn" and "postCallWithException" in
> following line:
> {code:java}
> token.getCoordination().end();
> {code}
> The "getCoordination()" call in above line is returning null.
> As I mentioned, it is happening from time to time. sometimes after 20 mins,
> sometimes after hours of test execution and it is happening in different
> transactional methods in different classes of the application.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (ARIES-1454) NPE in TxInterceptor
[
https://issues.apache.org/jira/browse/ARIES-1454?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15013424#comment-15013424
]
Christian Schneider commented on ARIES-1454:
I am not fully sure why this happens but I think we should catch or avoid the
exception. I have just committed a fix on trunk.
> NPE in TxInterceptor
>
>
> Key: ARIES-1454
> URL: https://issues.apache.org/jira/browse/ARIES-1454
> Project: Aries
> Issue Type: Bug
> Components: Transaction
>Affects Versions: transaction-blueprint-1.1.1
> Environment: Karaf 4.0.2 (Felix)
> JPA (Hibernate)
>Reporter: Mohammad Shamsi
> Fix For: transaction-3.0.0
>
>
> I am running some load tests agains an osgi app, which is running inside
> karaf 4.0.2, using Aries Blueprint and JPA (Hibernate) .
> The test is using multiple threads (10) to issue some random calls to the
> application.
> Sometimes, randomly, some of the call throwing NPE in TxInterceptor:
> {code:java}
> java.lang.NullPointerException
> at
> org.apache.aries.transaction.TxInterceptorImpl.postCallWithReturn(TxInterceptorImpl.java:101)[66:org.apache.aries.transaction.blueprint:1.1.1]
> at
> org.apache.aries.blueprint.proxy.SingleInterceptorCollaborator.postInvoke(SingleInterceptorCollaborator.java:75)[48:org.apache.aries.blueprint.core:1.4.4]
> at Proxy65968de8_a064_4203_9a53_5f0c8e536279.lockAll(Unknown
> Source)[:]
> {code}
> The NPE is thrown from "postCallWithReturn" and "postCallWithException" in
> following line:
> {code:java}
> token.getCoordination().end();
> {code}
> The "getCoordination()" call in above line is returning null.
> As I mentioned, it is happening from time to time. sometimes after 20 mins,
> sometimes after hours of test execution and it is happening in different
> transactional methods in different classes of the application.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (ARIES-1454) NPE in TxInterceptor
[
https://issues.apache.org/jira/browse/ARIES-1454?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15013424#comment-15013424
]
Christian Schneider edited comment on ARIES-1454 at 11/19/15 12:16 PM:
---
I am not fully sure why this happens but I think we should catch or avoid the
exception. I have just committed a fix on trunk.
See
https://github.com/apache/aries/commit/628523f8c990ab7dc9bb302567a497d60c3fd011
was (Author: ch...@die-schneider.net):
I am not fully sure why this happens but I think we should catch or avoid the
exception. I have just committed a fix on trunk.
> NPE in TxInterceptor
>
>
> Key: ARIES-1454
> URL: https://issues.apache.org/jira/browse/ARIES-1454
> Project: Aries
> Issue Type: Bug
> Components: Transaction
>Affects Versions: transaction-blueprint-1.1.1
> Environment: Karaf 4.0.2 (Felix)
> JPA (Hibernate)
>Reporter: Mohammad Shamsi
>Assignee: Christian Schneider
> Fix For: transaction-3.0.0
>
>
> I am running some load tests agains an osgi app, which is running inside
> karaf 4.0.2, using Aries Blueprint and JPA (Hibernate) .
> The test is using multiple threads (10) to issue some random calls to the
> application.
> Sometimes, randomly, some of the call throwing NPE in TxInterceptor:
> {code:java}
> java.lang.NullPointerException
> at
> org.apache.aries.transaction.TxInterceptorImpl.postCallWithReturn(TxInterceptorImpl.java:101)[66:org.apache.aries.transaction.blueprint:1.1.1]
> at
> org.apache.aries.blueprint.proxy.SingleInterceptorCollaborator.postInvoke(SingleInterceptorCollaborator.java:75)[48:org.apache.aries.blueprint.core:1.4.4]
> at Proxy65968de8_a064_4203_9a53_5f0c8e536279.lockAll(Unknown
> Source)[:]
> {code}
> The NPE is thrown from "postCallWithReturn" and "postCallWithException" in
> following line:
> {code:java}
> token.getCoordination().end();
> {code}
> The "getCoordination()" call in above line is returning null.
> As I mentioned, it is happening from time to time. sometimes after 20 mins,
> sometimes after hours of test execution and it is happening in different
> transactional methods in different classes of the application.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (ARIES-1454) NPE in TxInterceptor
[
https://issues.apache.org/jira/browse/ARIES-1454?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15013729#comment-15013729
]
Christian Schneider edited comment on ARIES-1454 at 11/19/15 3:48 PM:
--
I had a lot of problems with the GC when I started using the Coordinator. I
just called begin to put the coordination on the thread based stack. In this
case the GC indeed cleans it up.
Now it is different though. The Coordination should be stored on the
PrecallToken so the GC should not happen.
So I am not sure what is going on. Can you test with the code on trunk or do
you need a backport? (The transaction blueprint 2.0.0 has a new namespace and
works only with annoations).
was (Author: ch...@die-schneider.net):
I had a lot of problems with the GC when I started using the Coordinator. I
just called begin to put the coordination on the thread based stack. In this
case the GC indeed cleans it up.
Now it is different though. The Coordination should be stored on the
PrecallToken so the GC should not happen.
So I am not sure what is going on. Can you test with the code on trunk or do
you need a backport?
> NPE in TxInterceptor
>
>
> Key: ARIES-1454
> URL: https://issues.apache.org/jira/browse/ARIES-1454
> Project: Aries
> Issue Type: Bug
> Components: Transaction
>Affects Versions: transaction-blueprint-1.1.1
> Environment: Karaf 4.0.2 (Felix)
> JPA (Hibernate)
>Reporter: Mohammad Shamsi
>Assignee: Christian Schneider
> Fix For: transaction-3.0.0
>
>
> I am running some load tests agains an osgi app, which is running inside
> karaf 4.0.2, using Aries Blueprint and JPA (Hibernate) .
> The test is using multiple threads (10) to issue some random calls to the
> application.
> Sometimes, randomly, some of the call throwing NPE in TxInterceptor:
> {code:java}
> java.lang.NullPointerException
> at
> org.apache.aries.transaction.TxInterceptorImpl.postCallWithReturn(TxInterceptorImpl.java:101)[66:org.apache.aries.transaction.blueprint:1.1.1]
> at
> org.apache.aries.blueprint.proxy.SingleInterceptorCollaborator.postInvoke(SingleInterceptorCollaborator.java:75)[48:org.apache.aries.blueprint.core:1.4.4]
> at Proxy65968de8_a064_4203_9a53_5f0c8e536279.lockAll(Unknown
> Source)[:]
> {code}
> The NPE is thrown from "postCallWithReturn" and "postCallWithException" in
> following line:
> {code:java}
> token.getCoordination().end();
> {code}
> The "getCoordination()" call in above line is returning null.
> As I mentioned, it is happening from time to time. sometimes after 20 mins,
> sometimes after hours of test execution and it is happening in different
> transactional methods in different classes of the application.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (ARIES-1454) NPE in TxInterceptor
[
https://issues.apache.org/jira/browse/ARIES-1454?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15013729#comment-15013729
]
Christian Schneider commented on ARIES-1454:
I had a lot of problems with the GC when I started using the Coordinator. I
just called begin to put the coordination on the thread based stack. In this
case the GC indeed cleans it up.
Now it is different though. The Coordination should be stored on the
PrecallToken so the GC should not happen.
So I am not sure what is going on. Can you test with the code on trunk or do
you need a backport?
> NPE in TxInterceptor
>
>
> Key: ARIES-1454
> URL: https://issues.apache.org/jira/browse/ARIES-1454
> Project: Aries
> Issue Type: Bug
> Components: Transaction
>Affects Versions: transaction-blueprint-1.1.1
> Environment: Karaf 4.0.2 (Felix)
> JPA (Hibernate)
>Reporter: Mohammad Shamsi
>Assignee: Christian Schneider
> Fix For: transaction-3.0.0
>
>
> I am running some load tests agains an osgi app, which is running inside
> karaf 4.0.2, using Aries Blueprint and JPA (Hibernate) .
> The test is using multiple threads (10) to issue some random calls to the
> application.
> Sometimes, randomly, some of the call throwing NPE in TxInterceptor:
> {code:java}
> java.lang.NullPointerException
> at
> org.apache.aries.transaction.TxInterceptorImpl.postCallWithReturn(TxInterceptorImpl.java:101)[66:org.apache.aries.transaction.blueprint:1.1.1]
> at
> org.apache.aries.blueprint.proxy.SingleInterceptorCollaborator.postInvoke(SingleInterceptorCollaborator.java:75)[48:org.apache.aries.blueprint.core:1.4.4]
> at Proxy65968de8_a064_4203_9a53_5f0c8e536279.lockAll(Unknown
> Source)[:]
> {code}
> The NPE is thrown from "postCallWithReturn" and "postCallWithException" in
> following line:
> {code:java}
> token.getCoordination().end();
> {code}
> The "getCoordination()" call in above line is returning null.
> As I mentioned, it is happening from time to time. sometimes after 20 mins,
> sometimes after hours of test execution and it is happening in different
> transactional methods in different classes of the application.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (ARIES-1454) NPE in TxInterceptor
[
https://issues.apache.org/jira/browse/ARIES-1454?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15013768#comment-15013768
]
Christian Schneider commented on ARIES-1454:
In precall we have these two lines:
https://github.com/apache/aries/blob/trunk/transaction/transaction-blueprint/src/main/java/org/apache/aries/transaction/TxInterceptorImpl.java#L65-L66
As the coordination is kept in local reference and then stored in the
preCallToken the gc should not be a problem. Of course only if Coordinator is
working correctly.
> NPE in TxInterceptor
>
>
> Key: ARIES-1454
> URL: https://issues.apache.org/jira/browse/ARIES-1454
> Project: Aries
> Issue Type: Bug
> Components: Transaction
>Affects Versions: transaction-blueprint-1.1.1
> Environment: Karaf 4.0.2 (Felix)
> JPA (Hibernate)
>Reporter: Mohammad Shamsi
>Assignee: Christian Schneider
> Fix For: transaction-3.0.0
>
>
> I am running some load tests agains an osgi app, which is running inside
> karaf 4.0.2, using Aries Blueprint and JPA (Hibernate) .
> The test is using multiple threads (10) to issue some random calls to the
> application.
> Sometimes, randomly, some of the call throwing NPE in TxInterceptor:
> {code:java}
> java.lang.NullPointerException
> at
> org.apache.aries.transaction.TxInterceptorImpl.postCallWithReturn(TxInterceptorImpl.java:101)[66:org.apache.aries.transaction.blueprint:1.1.1]
> at
> org.apache.aries.blueprint.proxy.SingleInterceptorCollaborator.postInvoke(SingleInterceptorCollaborator.java:75)[48:org.apache.aries.blueprint.core:1.4.4]
> at Proxy65968de8_a064_4203_9a53_5f0c8e536279.lockAll(Unknown
> Source)[:]
> {code}
> The NPE is thrown from "postCallWithReturn" and "postCallWithException" in
> following line:
> {code:java}
> token.getCoordination().end();
> {code}
> The "getCoordination()" call in above line is returning null.
> As I mentioned, it is happening from time to time. sometimes after 20 mins,
> sometimes after hours of test execution and it is happening in different
> transactional methods in different classes of the application.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (ARIES-1454) NPE in TxInterceptor
[
https://issues.apache.org/jira/browse/ARIES-1454?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15013807#comment-15013807
]
Christian Schneider commented on ARIES-1454:
In fact it is probably the only explanation how the NPE can happen. At least if
we assume that preCall is always called.
> NPE in TxInterceptor
>
>
> Key: ARIES-1454
> URL: https://issues.apache.org/jira/browse/ARIES-1454
> Project: Aries
> Issue Type: Bug
> Components: Transaction
>Affects Versions: transaction-blueprint-1.1.1
> Environment: Karaf 4.0.2 (Felix)
> JPA (Hibernate)
>Reporter: Mohammad Shamsi
>Assignee: Christian Schneider
> Fix For: transaction-3.0.0
>
>
> I am running some load tests agains an osgi app, which is running inside
> karaf 4.0.2, using Aries Blueprint and JPA (Hibernate) .
> The test is using multiple threads (10) to issue some random calls to the
> application.
> Sometimes, randomly, some of the call throwing NPE in TxInterceptor:
> {code:java}
> java.lang.NullPointerException
> at
> org.apache.aries.transaction.TxInterceptorImpl.postCallWithReturn(TxInterceptorImpl.java:101)[66:org.apache.aries.transaction.blueprint:1.1.1]
> at
> org.apache.aries.blueprint.proxy.SingleInterceptorCollaborator.postInvoke(SingleInterceptorCollaborator.java:75)[48:org.apache.aries.blueprint.core:1.4.4]
> at Proxy65968de8_a064_4203_9a53_5f0c8e536279.lockAll(Unknown
> Source)[:]
> {code}
> The NPE is thrown from "postCallWithReturn" and "postCallWithException" in
> following line:
> {code:java}
> token.getCoordination().end();
> {code}
> The "getCoordination()" call in above line is returning null.
> As I mentioned, it is happening from time to time. sometimes after 20 mins,
> sometimes after hours of test execution and it is happening in different
> transactional methods in different classes of the application.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (ARIES-1455) JpaComponentProcessor is not scanning the nested beans inside service definition
[
https://issues.apache.org/jira/browse/ARIES-1455?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15015390#comment-15015390
]
Christian Schneider commented on ARIES-1455:
Thanks for the issue. Do you also plan to provide a fix in form of a pull
request?
If not I can start working on it.
> JpaComponentProcessor is not scanning the nested beans inside service
> definition
>
>
> Key: ARIES-1455
> URL: https://issues.apache.org/jira/browse/ARIES-1455
> Project: Aries
> Issue Type: Bug
> Components: Blueprint, JPA
>Affects Versions: jpa-2.2.0
>Reporter: Mohammad Shamsi
>
> Given following blueprint definition:
> {code:xml}
>
>
>
>
>
> {code}
> MyDaoImpl has a property of type EntityManager annotated with PersistenceUnit
> but "JpaComponentProcessor" is not able to properly scan the nested bean
> inside above service definition to find the annotated property.
> looking at JpaComponentProcessor source, following code snippet, one can see
> it
> is checking if component definition is an instance of "MutableBeanMetadata"
> which is not the case when the bean definition is nested in service
> definition (it is an instance of "MutableServiceMetadata")
> {code:java}
> Set components = new
> HashSet for (String component : components) {
> ComponentMetadata compDef = cdr.getComponentDefinition(component);
> if (compDef instanceof MutableBeanMetadata &&
> !((MutableBeanMetadata)compDef).isProcessor()) {
> handleComponent((MutableBeanMetadata)compDef, bundle, cdr,
> container);
> }
> }
> {code}
> As a workaround I can change the blueprint definition to following:
> {code:xml}
>
>
>
>
>
>
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (ARIES-1455) JpaComponentProcessor is not scanning the nested beans inside service definition
[
https://issues.apache.org/jira/browse/ARIES-1455?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christian Schneider reassigned ARIES-1455:
--
Assignee: Christian Schneider
> JpaComponentProcessor is not scanning the nested beans inside service
> definition
>
>
> Key: ARIES-1455
> URL: https://issues.apache.org/jira/browse/ARIES-1455
> Project: Aries
> Issue Type: Bug
> Components: Blueprint, JPA
>Affects Versions: jpa-2.2.0
>Reporter: Mohammad Shamsi
> Assignee: Christian Schneider
>
> Given following blueprint definition:
> {code:xml}
>
>
>
>
>
> {code}
> MyDaoImpl has a property of type EntityManager annotated with PersistenceUnit
> but "JpaComponentProcessor" is not able to properly scan the nested bean
> inside above service definition to find the annotated property.
> looking at JpaComponentProcessor source, following code snippet, one can see
> it
> is checking if component definition is an instance of "MutableBeanMetadata"
> which is not the case when the bean definition is nested in service
> definition (it is an instance of "MutableServiceMetadata")
> {code:java}
> Set components = new
> HashSet for (String component : components) {
> ComponentMetadata compDef = cdr.getComponentDefinition(component);
> if (compDef instanceof MutableBeanMetadata &&
> !((MutableBeanMetadata)compDef).isProcessor()) {
> handleComponent((MutableBeanMetadata)compDef, bundle, cdr,
> container);
> }
> }
> {code}
> As a workaround I can change the blueprint definition to following:
> {code:xml}
>
>
>
>
>
>
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (ARIES-1464) Improve blueprint-maven-plugin: add @Scope support
[
https://issues.apache.org/jira/browse/ARIES-1464?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christian Schneider reassigned ARIES-1464:
--
Assignee: Christian Schneider
> Improve blueprint-maven-plugin: add @Scope support
> --
>
> Key: ARIES-1464
> URL: https://issues.apache.org/jira/browse/ARIES-1464
> Project: Aries
> Issue Type: Improvement
> Components: Blueprint
>Reporter: Sam Wright
> Assignee: Christian Schneider
>
> I propose adding support for configuring bean scope using
> blueprint-maven-plugin, e.g. annotating a class with `@Scope("prototype")`
> will add `scope = "prototype"` to the bean's xml element.
> [~ch...@die-schneider.net] is probably the person to review this.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (ARIES-1466) New JPA and Transaction xml schema should be published
[ https://issues.apache.org/jira/browse/ARIES-1466?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schneider reassigned ARIES-1466: -- Assignee: Christian Schneider > New JPA and Transaction xml schema should be published > -- > > Key: ARIES-1466 > URL: https://issues.apache.org/jira/browse/ARIES-1466 > Project: Aries > Issue Type: Task > Components: JPA, Transaction >Affects Versions: jpa-2.2.0, transaction-blueprint-2.0.0 >Reporter: Viktor Kozlov >Assignee: Christian Schneider >Priority: Minor > > Users have to use these links to sources now: > https://raw.githubusercontent.com/apache/aries/trunk/jpa/jpa-blueprint/src/main/resources/jpa20.xsd > https://raw.githubusercontent.com/apache/aries/trunk/transaction/transaction-blueprint/src/main/resources/org/apache/aries/transaction/parsing/transactionv20.xsd > It will be nice we publish xsds somewhere on Aries site. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (ARIES-1466) New JPA and Transaction xml schema should be published
[ https://issues.apache.org/jira/browse/ARIES-1466?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schneider resolved ARIES-1466. Resolution: Fixed The schemas are published on the schema directory of the website now. I will also add links from the respective documentation pages. > New JPA and Transaction xml schema should be published > -- > > Key: ARIES-1466 > URL: https://issues.apache.org/jira/browse/ARIES-1466 > Project: Aries > Issue Type: Task > Components: JPA, Transaction >Affects Versions: jpa-2.2.0, transaction-blueprint-2.0.0 >Reporter: Viktor Kozlov >Assignee: Christian Schneider >Priority: Minor > > Users have to use these links to sources now: > https://raw.githubusercontent.com/apache/aries/trunk/jpa/jpa-blueprint/src/main/resources/jpa20.xsd > https://raw.githubusercontent.com/apache/aries/trunk/transaction/transaction-blueprint/src/main/resources/org/apache/aries/transaction/parsing/transactionv20.xsd > It will be nice we publish xsds somewhere on Aries site. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (ARIES-1466) New JPA and Transaction xml schema should be published
[ https://issues.apache.org/jira/browse/ARIES-1466?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15041522#comment-15041522 ] Christian Schneider commented on ARIES-1466: I now also found out how to create the redirections. So you can type the namespace in the browser and get the xsd location. > New JPA and Transaction xml schema should be published > -- > > Key: ARIES-1466 > URL: https://issues.apache.org/jira/browse/ARIES-1466 > Project: Aries > Issue Type: Task > Components: JPA, Transaction >Affects Versions: jpa-2.2.0, transaction-blueprint-2.0.0 >Reporter: Viktor Kozlov >Assignee: Christian Schneider >Priority: Minor > > Users have to use these links to sources now: > https://raw.githubusercontent.com/apache/aries/trunk/jpa/jpa-blueprint/src/main/resources/jpa20.xsd > https://raw.githubusercontent.com/apache/aries/trunk/transaction/transaction-blueprint/src/main/resources/org/apache/aries/transaction/parsing/transactionv20.xsd > It will be nice we publish xsds somewhere on Aries site. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (ARIES-1469) JPA container should not embed spec packages
Christian Schneider created ARIES-1469: -- Summary: JPA container should not embed spec packages Key: ARIES-1469 URL: https://issues.apache.org/jira/browse/ARIES-1469 Project: Aries Issue Type: Bug Components: JPA Affects Versions: jpa-2.2.0 Reporter: Christian Schneider Assignee: Christian Schneider Fix For: jpa-2.3.0 Currently Aries JPA container embeds two spec packages: org.osgi.service.jdbc and org.osgi.service.jpa. These packages are now also provided by bundles provided by the OSGi alliance. So we should remove the embedding and instead install the official bundles. This will avoid problems like the linked issue reported at pax jdbc where the spec package is provided by different bundles. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (ARIES-1469) JPA container should not embed spec packages
[ https://issues.apache.org/jira/browse/ARIES-1469?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schneider resolved ARIES-1469. Resolution: Fixed > JPA container should not embed spec packages > > > Key: ARIES-1469 > URL: https://issues.apache.org/jira/browse/ARIES-1469 > Project: Aries > Issue Type: Bug > Components: JPA >Affects Versions: jpa-2.2.0 > Reporter: Christian Schneider >Assignee: Christian Schneider > Fix For: jpa-2.3.0 > > > Currently Aries JPA container embeds two spec packages: > org.osgi.service.jdbc and org.osgi.service.jpa. > These packages are now also provided by bundles provided by the OSGi > alliance. So we should remove the embedding and instead install the official > bundles. > This will avoid problems like the linked issue reported at pax jdbc where > the spec package is provided by different bundles. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (ARIES-1468) Aries Transaction Blueprint bundle fails to start sometimes
[ https://issues.apache.org/jira/browse/ARIES-1468?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15048304#comment-15048304 ] Christian Schneider commented on ARIES-1468: Can you post the jmx exception too? I think it is the core of the problem but I was not able to find it. > Aries Transaction Blueprint bundle fails to start sometimes > --- > > Key: ARIES-1468 > URL: https://issues.apache.org/jira/browse/ARIES-1468 > Project: Aries > Issue Type: Bug > Components: JMX, Transaction >Affects Versions: transaction-manager-1.3.0, jmx-1.1.5, > transaction-blueprint-2.0.0 > Environment: Windows 7 version 6.1 x64 > Java 1.7.0_80 x64 >Reporter: Viktor Kozlov >Priority: Blocker > Fix For: jmx-1.1.6 > > > I have found some unstable behavior when starting Karaf 4.0.3. > Apache Aries Transaction Blueprint 2.0.0 bundle start success is random. > I have to restart Karaf several (about 3 to 10) times to get the error. > It looks like it is some sort of a bundle race or something. > The list of features to be installed: > feature:install -v eventadmin; > feature:install -v http-whiteboard; > feature:install -v jdbc; > feature:install -v pax-jdbc-pool-dbcp2; > feature:install -v eclipselink/2.6.0; > feature:install -v jpa/2.2.0; > Exception during Karaf start: > karaf@root()> ERROR: Bundle org.apache.aries.blueprint.core [13] > EventDispatcher: Error during dispatch. (java.lang.NullPointerException) > java.lang.NullPointerException > at > org.apache.aries.blueprint.namespace.NamespaceHandlerRegistryImpl.addingService(NamespaceHandlerRegistryImpl.java:126) > at > org.osgi.util.tracker.ServiceTracker$Tracked.customizerAdding(ServiceTracker.java:941) > at > org.osgi.util.tracker.ServiceTracker$Tracked.customizerAdding(ServiceTracker.java:870) > at > org.osgi.util.tracker.AbstractTracked.trackAdding(AbstractTracked.java:256) > at > org.osgi.util.tracker.AbstractTracked.track(AbstractTracked.java:229) > at > org.osgi.util.tracker.ServiceTracker$Tracked.serviceChanged(ServiceTracker.java:901) > at > org.apache.felix.framework.util.EventDispatcher.invokeServiceListenerCallback(EventDispatcher.java:991) > at > org.apache.felix.framework.util.EventDispatcher.fireEventImmediately(EventDispatcher.java:839) > at > org.apache.felix.framework.util.EventDispatcher.fireServiceEvent(EventDispatcher.java:546) > at org.apache.felix.framework.Felix.fireServiceEvent(Felix.java:4557) > at org.apache.felix.framework.Felix.registerService(Felix.java:3549) > at > org.apache.felix.framework.BundleContextImpl.registerService(BundleContextImpl.java:348) > at > org.apache.aries.blueprint.container.BlueprintContainerImpl.registerService(BlueprintContainerImpl.java:459) > at > org.apache.aries.blueprint.container.ServiceRecipe.register(ServiceRecipe.java:193) > at > org.apache.aries.blueprint.container.BlueprintContainerImpl.registerServices(BlueprintContainerImpl.java:710) > at > org.apache.aries.blueprint.container.BlueprintContainerImpl.doRun(BlueprintContainerImpl.java:385) > at > org.apache.aries.blueprint.container.BlueprintContainerImpl.run(BlueprintContainerImpl.java:270) > at > java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) > at java.util.concurrent.FutureTask.run(FutureTask.java:262) > at > org.apache.aries.blueprint.container.ExecutorServiceWrapper.run(ExecutorServiceWrapper.java:106) > at > org.apache.aries.blueprint.utils.threading.impl.DiscardableRunnable.run(DiscardableRunnable.java:48) > at > java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) > at java.util.concurrent.FutureTask.run(FutureTask.java:262) > at > java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:178) > at > java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:292) > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) > at java.lang.Thread.run(Thread.java:745) > Cut from bundle:list command result: > 108 | Active | 80 | 1.2 | javax.interceptor API > 109 | Active | 80 | 1.2 | javax.tran
[jira] [Comment Edited] (ARIES-1468) Aries Transaction Blueprint bundle fails to start sometimes
[ https://issues.apache.org/jira/browse/ARIES-1468?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15048304#comment-15048304 ] Christian Schneider edited comment on ARIES-1468 at 12/9/15 8:49 AM: - Never mind ... I found the jmx exception in the log: [org.osgi.framework.ServiceEvent[source=[org.apache.aries.blueprint.NamespaceHandler]]] java.lang.NullPointerException at org.apache.aries.jmx.codec.ServiceEventData.(ServiceEventData.java:90)[18:org.apache.aries.jmx.core:1.1.5] at org.apache.aries.jmx.framework.ServiceState$1.serviceChanged(ServiceState.java:261)[18:org.apache.aries.jmx.core:1.1.5] at org.apache.felix.framework.util.EventDispatcher.invokeServiceListenerCallback(EventDispatcher.java:991)[org.apache.felix.framework-5.4.0.jar:] at org.apache.felix.framework.util.EventDispatcher.fireEventImmediately(EventDispatcher.java:839)[org.apache.felix.framework-5.4.0.jar:] at org.apache.felix.framework.util.EventDispatcher.fireServiceEvent(EventDispatcher.java:546)[org.apache.felix.framework-5.4.0.jar:] at org.apache.felix.framework.Felix.fireServiceEvent(Felix.java:4557)[org.apache.felix.framework-5.4.0.jar:] at org.apache.felix.framework.Felix.registerService(Felix.java:3549)[org.apache.felix.framework-5.4.0.jar:] at org.apache.felix.framework.BundleContextImpl.registerService(BundleContextImpl.java:348)[org.apache.felix.framework-5.4.0.jar:] at org.apache.aries.blueprint.container.BlueprintContainerImpl.registerService(BlueprintContainerImpl.java:459)[13:org.apache.aries.blueprint.core:1.4.5] at org.apache.aries.blueprint.container.ServiceRecipe.register(ServiceRecipe.java:193)[13:org.apache.aries.blueprint.core:1.4.5] at org.apache.aries.blueprint.container.BlueprintContainerImpl.registerServices(BlueprintContainerImpl.java:710)[13:org.apache.aries.blueprint.core:1.4.5] at org.apache.aries.blueprint.container.BlueprintContainerImpl.doRun(BlueprintContainerImpl.java:385)[13:org.apache.aries.blueprint.core:1.4.5] at org.apache.aries.blueprint.container.BlueprintContainerImpl.run(BlueprintContainerImpl.java:270)[13:org.apache.aries.blueprint.core:1.4.5] at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)[:1.7.0_80] at java.util.concurrent.FutureTask.run(FutureTask.java:262)[:1.7.0_80] at org.apache.aries.blueprint.container.ExecutorServiceWrapper.run(ExecutorServiceWrapper.java:106)[13:org.apache.aries.blueprint.core:1.4.5] at org.apache.aries.blueprint.utils.threading.impl.DiscardableRunnable.run(DiscardableRunnable.java:48)[13:org.apache.aries.blueprint.core:1.4.5] at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)[:1.7.0_80] at java.util.concurrent.FutureTask.run(FutureTask.java:262)[:1.7.0_80] at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:178)[:1.7.0_80] at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:292)[:1.7.0_80] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)[:1.7.0_80] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)[:1.7.0_80] at java.lang.Thread.run(Thread.java:745)[:1.7.0_80] was (Author: ch...@die-schneider.net): Can you post the jmx exception too? I think it is the core of the problem but I was not able to find it. > Aries Transaction Blueprint bundle fails to start sometimes > --- > > Key: ARIES-1468 > URL: https://issues.apache.org/jira/browse/ARIES-1468 > Project: Aries > Issue Type: Bug > Components: JMX, Transaction >Affects Versions: transaction-manager-1.3.0, jmx-1.1.5, > transaction-blueprint-2.0.0 > Environment: Windows 7 version 6.1 x64 > Java 1.7.0_80 x64 >Reporter: Viktor Kozlov >Priority: Blocker > Fix For: jmx-1.1.6 > > > I have found some unstable behavior when starting Karaf 4.0.3. > Apache Aries Transaction Blueprint 2.0.0 bundle start success is random. > I have to restart Karaf several (about 3 to 10) times to get the error. > It looks like it is some sort of a bundle race or something. > The list of features to be installed: > feature:install -v eventadmin; > feature:install -v http-whiteboard; > feature:install -v jdbc; > feature:install -v pax-jdbc-pool-dbcp2; > feature:install -v eclipselink/2.6.0; > feature:install -v jpa/2.2.0; > Exception during Karaf start: > karaf@root()> ERROR: Bundle org.apache.aries.blueprint.core [13] > Event
[jira] [Resolved] (ARIES-1455) JpaComponentProcessor is not scanning the nested beans inside service definition
[
https://issues.apache.org/jira/browse/ARIES-1455?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christian Schneider resolved ARIES-1455.
Resolution: Fixed
Fix Version/s: jpa-2.3.0
https://github.com/apache/aries/commit/37265e0a7e9dda58001af8f845638ac0640fec52
> JpaComponentProcessor is not scanning the nested beans inside service
> definition
>
>
> Key: ARIES-1455
> URL: https://issues.apache.org/jira/browse/ARIES-1455
> Project: Aries
> Issue Type: Bug
> Components: Blueprint, JPA
>Affects Versions: jpa-2.2.0
>Reporter: Mohammad Shamsi
> Assignee: Christian Schneider
> Fix For: jpa-2.3.0
>
>
> Given following blueprint definition:
> {code:xml}
>
>
>
>
>
> {code}
> MyDaoImpl has a property of type EntityManager annotated with PersistenceUnit
> but "JpaComponentProcessor" is not able to properly scan the nested bean
> inside above service definition to find the annotated property.
> looking at JpaComponentProcessor source, following code snippet, one can see
> it
> is checking if component definition is an instance of "MutableBeanMetadata"
> which is not the case when the bean definition is nested in service
> definition (it is an instance of "MutableServiceMetadata")
> {code:java}
> Set components = new
> HashSet for (String component : components) {
> ComponentMetadata compDef = cdr.getComponentDefinition(component);
> if (compDef instanceof MutableBeanMetadata &&
> !((MutableBeanMetadata)compDef).isProcessor()) {
> handleComponent((MutableBeanMetadata)compDef, bundle, cdr,
> container);
> }
> }
> {code}
> As a workaround I can change the blueprint definition to following:
> {code:xml}
>
>
>
>
>
>
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (ARIES-1468) Aries Transaction Blueprint bundle fails to start sometimes
[ https://issues.apache.org/jira/browse/ARIES-1468?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schneider reassigned ARIES-1468: -- Assignee: Christian Schneider > Aries Transaction Blueprint bundle fails to start sometimes > --- > > Key: ARIES-1468 > URL: https://issues.apache.org/jira/browse/ARIES-1468 > Project: Aries > Issue Type: Bug > Components: JMX, Transaction >Affects Versions: transaction-manager-1.3.0, jmx-1.1.5, > transaction-blueprint-2.0.0 > Environment: Windows 7 version 6.1 x64 > Java 1.7.0_80 x64 >Reporter: Viktor Kozlov >Assignee: Christian Schneider >Priority: Blocker > Fix For: jmx-1.1.6 > > > I have found some unstable behavior when starting Karaf 4.0.3. > Apache Aries Transaction Blueprint 2.0.0 bundle start success is random. > I have to restart Karaf several (about 3 to 10) times to get the error. > It looks like it is some sort of a bundle race or something. > The list of features to be installed: > feature:install -v eventadmin; > feature:install -v http-whiteboard; > feature:install -v jdbc; > feature:install -v pax-jdbc-pool-dbcp2; > feature:install -v eclipselink/2.6.0; > feature:install -v jpa/2.2.0; > Exception during Karaf start: > karaf@root()> ERROR: Bundle org.apache.aries.blueprint.core [13] > EventDispatcher: Error during dispatch. (java.lang.NullPointerException) > java.lang.NullPointerException > at > org.apache.aries.blueprint.namespace.NamespaceHandlerRegistryImpl.addingService(NamespaceHandlerRegistryImpl.java:126) > at > org.osgi.util.tracker.ServiceTracker$Tracked.customizerAdding(ServiceTracker.java:941) > at > org.osgi.util.tracker.ServiceTracker$Tracked.customizerAdding(ServiceTracker.java:870) > at > org.osgi.util.tracker.AbstractTracked.trackAdding(AbstractTracked.java:256) > at > org.osgi.util.tracker.AbstractTracked.track(AbstractTracked.java:229) > at > org.osgi.util.tracker.ServiceTracker$Tracked.serviceChanged(ServiceTracker.java:901) > at > org.apache.felix.framework.util.EventDispatcher.invokeServiceListenerCallback(EventDispatcher.java:991) > at > org.apache.felix.framework.util.EventDispatcher.fireEventImmediately(EventDispatcher.java:839) > at > org.apache.felix.framework.util.EventDispatcher.fireServiceEvent(EventDispatcher.java:546) > at org.apache.felix.framework.Felix.fireServiceEvent(Felix.java:4557) > at org.apache.felix.framework.Felix.registerService(Felix.java:3549) > at > org.apache.felix.framework.BundleContextImpl.registerService(BundleContextImpl.java:348) > at > org.apache.aries.blueprint.container.BlueprintContainerImpl.registerService(BlueprintContainerImpl.java:459) > at > org.apache.aries.blueprint.container.ServiceRecipe.register(ServiceRecipe.java:193) > at > org.apache.aries.blueprint.container.BlueprintContainerImpl.registerServices(BlueprintContainerImpl.java:710) > at > org.apache.aries.blueprint.container.BlueprintContainerImpl.doRun(BlueprintContainerImpl.java:385) > at > org.apache.aries.blueprint.container.BlueprintContainerImpl.run(BlueprintContainerImpl.java:270) > at > java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) > at java.util.concurrent.FutureTask.run(FutureTask.java:262) > at > org.apache.aries.blueprint.container.ExecutorServiceWrapper.run(ExecutorServiceWrapper.java:106) > at > org.apache.aries.blueprint.utils.threading.impl.DiscardableRunnable.run(DiscardableRunnable.java:48) > at > java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) > at java.util.concurrent.FutureTask.run(FutureTask.java:262) > at > java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:178) > at > java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:292) > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) > at java.lang.Thread.run(Thread.java:745) > Cut from bundle:list command result: > 108 | Active | 80 | 1.2 | javax.interceptor API > 109 | Active | 80 | 1.2 | javax.transaction API > 110 | Active | 80 | 1.1.1 | Apache Aries Tr
[jira] [Commented] (ARIES-1468) Aries Transaction Blueprint bundle fails to start sometimes
[ https://issues.apache.org/jira/browse/ARIES-1468?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15048401#comment-15048401 ] Christian Schneider commented on ARIES-1468: Fixed in trunk: https://github.com/apache/aries/commit/b6ff6c1f3cb3ac12d6bff6f2c5ea6160b5abbe15 Can you test if this works for you? > Aries Transaction Blueprint bundle fails to start sometimes > --- > > Key: ARIES-1468 > URL: https://issues.apache.org/jira/browse/ARIES-1468 > Project: Aries > Issue Type: Bug > Components: JMX, Transaction >Affects Versions: transaction-manager-1.3.0, jmx-1.1.5, > transaction-blueprint-2.0.0 > Environment: Windows 7 version 6.1 x64 > Java 1.7.0_80 x64 >Reporter: Viktor Kozlov >Assignee: Christian Schneider >Priority: Blocker > Fix For: jmx-1.1.6 > > > I have found some unstable behavior when starting Karaf 4.0.3. > Apache Aries Transaction Blueprint 2.0.0 bundle start success is random. > I have to restart Karaf several (about 3 to 10) times to get the error. > It looks like it is some sort of a bundle race or something. > The list of features to be installed: > feature:install -v eventadmin; > feature:install -v http-whiteboard; > feature:install -v jdbc; > feature:install -v pax-jdbc-pool-dbcp2; > feature:install -v eclipselink/2.6.0; > feature:install -v jpa/2.2.0; > Exception during Karaf start: > karaf@root()> ERROR: Bundle org.apache.aries.blueprint.core [13] > EventDispatcher: Error during dispatch. (java.lang.NullPointerException) > java.lang.NullPointerException > at > org.apache.aries.blueprint.namespace.NamespaceHandlerRegistryImpl.addingService(NamespaceHandlerRegistryImpl.java:126) > at > org.osgi.util.tracker.ServiceTracker$Tracked.customizerAdding(ServiceTracker.java:941) > at > org.osgi.util.tracker.ServiceTracker$Tracked.customizerAdding(ServiceTracker.java:870) > at > org.osgi.util.tracker.AbstractTracked.trackAdding(AbstractTracked.java:256) > at > org.osgi.util.tracker.AbstractTracked.track(AbstractTracked.java:229) > at > org.osgi.util.tracker.ServiceTracker$Tracked.serviceChanged(ServiceTracker.java:901) > at > org.apache.felix.framework.util.EventDispatcher.invokeServiceListenerCallback(EventDispatcher.java:991) > at > org.apache.felix.framework.util.EventDispatcher.fireEventImmediately(EventDispatcher.java:839) > at > org.apache.felix.framework.util.EventDispatcher.fireServiceEvent(EventDispatcher.java:546) > at org.apache.felix.framework.Felix.fireServiceEvent(Felix.java:4557) > at org.apache.felix.framework.Felix.registerService(Felix.java:3549) > at > org.apache.felix.framework.BundleContextImpl.registerService(BundleContextImpl.java:348) > at > org.apache.aries.blueprint.container.BlueprintContainerImpl.registerService(BlueprintContainerImpl.java:459) > at > org.apache.aries.blueprint.container.ServiceRecipe.register(ServiceRecipe.java:193) > at > org.apache.aries.blueprint.container.BlueprintContainerImpl.registerServices(BlueprintContainerImpl.java:710) > at > org.apache.aries.blueprint.container.BlueprintContainerImpl.doRun(BlueprintContainerImpl.java:385) > at > org.apache.aries.blueprint.container.BlueprintContainerImpl.run(BlueprintContainerImpl.java:270) > at > java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) > at java.util.concurrent.FutureTask.run(FutureTask.java:262) > at > org.apache.aries.blueprint.container.ExecutorServiceWrapper.run(ExecutorServiceWrapper.java:106) > at > org.apache.aries.blueprint.utils.threading.impl.DiscardableRunnable.run(DiscardableRunnable.java:48) > at > java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) > at java.util.concurrent.FutureTask.run(FutureTask.java:262) > at > java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:178) > at > java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:292) > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) > at java.lang.Thread.run(Thread.java:745) > Cut from bundle:list command result: > 108 | Active | 80 | 1.2 | javax.interce
[jira] [Commented] (ARIES-1468) Aries Transaction Blueprint bundle fails to start sometimes
[
https://issues.apache.org/jira/browse/ARIES-1468?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15048464#comment-15048464
]
Christian Schneider commented on ARIES-1468:
Just checkout the source from svn and then:
{code}
cd jmx
mvn clean install
{code}
It is quite handy to be able to build the snapshots yourself.
I also just deployed the current snapshot to
https://repository.apache.org/content/groups/snapshots/org/apache/aries/jmx/org.apache.aries.jmx.core/1.1.6-SNAPSHOT/
The snapshot repo should already be part of your karaf config.
So the easiest way to install is probably to change the karaf feature in the
system dir to point to the new snapshot version.
> Aries Transaction Blueprint bundle fails to start sometimes
> ---
>
> Key: ARIES-1468
> URL: https://issues.apache.org/jira/browse/ARIES-1468
> Project: Aries
> Issue Type: Bug
> Components: JMX, Transaction
>Affects Versions: transaction-manager-1.3.0, jmx-1.1.5,
> transaction-blueprint-2.0.0
> Environment: Windows 7 version 6.1 x64
> Java 1.7.0_80 x64
>Reporter: Viktor Kozlov
>Assignee: Christian Schneider
>Priority: Blocker
> Fix For: jmx-1.1.6
>
>
> I have found some unstable behavior when starting Karaf 4.0.3.
> Apache Aries Transaction Blueprint 2.0.0 bundle start success is random.
> I have to restart Karaf several (about 3 to 10) times to get the error.
> It looks like it is some sort of a bundle race or something.
> The list of features to be installed:
> feature:install -v eventadmin;
> feature:install -v http-whiteboard;
> feature:install -v jdbc;
> feature:install -v pax-jdbc-pool-dbcp2;
> feature:install -v eclipselink/2.6.0;
> feature:install -v jpa/2.2.0;
> Exception during Karaf start:
> karaf@root()> ERROR: Bundle org.apache.aries.blueprint.core [13]
> EventDispatcher: Error during dispatch. (java.lang.NullPointerException)
> java.lang.NullPointerException
> at
> org.apache.aries.blueprint.namespace.NamespaceHandlerRegistryImpl.addingService(NamespaceHandlerRegistryImpl.java:126)
> at
> org.osgi.util.tracker.ServiceTracker$Tracked.customizerAdding(ServiceTracker.java:941)
> at
> org.osgi.util.tracker.ServiceTracker$Tracked.customizerAdding(ServiceTracker.java:870)
> at
> org.osgi.util.tracker.AbstractTracked.trackAdding(AbstractTracked.java:256)
> at
> org.osgi.util.tracker.AbstractTracked.track(AbstractTracked.java:229)
> at
> org.osgi.util.tracker.ServiceTracker$Tracked.serviceChanged(ServiceTracker.java:901)
> at
> org.apache.felix.framework.util.EventDispatcher.invokeServiceListenerCallback(EventDispatcher.java:991)
> at
> org.apache.felix.framework.util.EventDispatcher.fireEventImmediately(EventDispatcher.java:839)
> at
> org.apache.felix.framework.util.EventDispatcher.fireServiceEvent(EventDispatcher.java:546)
> at org.apache.felix.framework.Felix.fireServiceEvent(Felix.java:4557)
> at org.apache.felix.framework.Felix.registerService(Felix.java:3549)
> at
> org.apache.felix.framework.BundleContextImpl.registerService(BundleContextImpl.java:348)
> at
> org.apache.aries.blueprint.container.BlueprintContainerImpl.registerService(BlueprintContainerImpl.java:459)
> at
> org.apache.aries.blueprint.container.ServiceRecipe.register(ServiceRecipe.java:193)
> at
> org.apache.aries.blueprint.container.BlueprintContainerImpl.registerServices(BlueprintContainerImpl.java:710)
> at
> org.apache.aries.blueprint.container.BlueprintContainerImpl.doRun(BlueprintContainerImpl.java:385)
> at
> org.apache.aries.blueprint.container.BlueprintContainerImpl.run(BlueprintContainerImpl.java:270)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
> at java.util.concurrent.FutureTask.run(FutureTask.java:262)
> at
> org.apache.aries.blueprint.container.ExecutorServiceWrapper.run(ExecutorServiceWrapper.java:106)
> at
> org.apache.aries.blueprint.utils.threading.impl.DiscardableRunnable.run(DiscardableRunnable.java:48)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
> at java.util.concurrent.FutureTask.run(FutureTask.java:262)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:178)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:29
[jira] [Commented] (ARIES-1468) Aries Transaction Blueprint bundle fails to start sometimes
[ https://issues.apache.org/jira/browse/ARIES-1468?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15048742#comment-15048742 ] Christian Schneider commented on ARIES-1468: This might be something for you [~gnt]. I do not fully understand the code where this exception happens: https://github.com/apache/aries/blob/trunk/blueprint/blueprint-core/src/main/java/org/apache/aries/blueprint/container/ServiceRecipe.java#L192-L197 Somehow it seems that the service registration has already been changed while the registration happens. I am not sure where this could happen though. Any ideas? > Aries Transaction Blueprint bundle fails to start sometimes > --- > > Key: ARIES-1468 > URL: https://issues.apache.org/jira/browse/ARIES-1468 > Project: Aries > Issue Type: Bug > Components: JMX, Transaction >Affects Versions: transaction-manager-1.3.0, jmx-1.1.5, > transaction-blueprint-2.0.0 > Environment: Windows 7 version 6.1 x64 > Java 1.7.0_80 x64 >Reporter: Viktor Kozlov >Assignee: Christian Schneider >Priority: Blocker > Fix For: jmx-1.1.6 > > > I have found some unstable behavior when starting Karaf 4.0.3. > Apache Aries Transaction Blueprint 2.0.0 bundle start success is random. > I have to restart Karaf several (about 3 to 10) times to get the error. > It looks like it is some sort of a bundle race or something. > The list of features to be installed: > feature:install -v eventadmin; > feature:install -v http-whiteboard; > feature:install -v jdbc; > feature:install -v pax-jdbc-pool-dbcp2; > feature:install -v eclipselink/2.6.0; > feature:install -v jpa/2.2.0; > Exception during Karaf start: > karaf@root()> ERROR: Bundle org.apache.aries.blueprint.core [13] > EventDispatcher: Error during dispatch. (java.lang.NullPointerException) > java.lang.NullPointerException > at > org.apache.aries.blueprint.namespace.NamespaceHandlerRegistryImpl.addingService(NamespaceHandlerRegistryImpl.java:126) > at > org.osgi.util.tracker.ServiceTracker$Tracked.customizerAdding(ServiceTracker.java:941) > at > org.osgi.util.tracker.ServiceTracker$Tracked.customizerAdding(ServiceTracker.java:870) > at > org.osgi.util.tracker.AbstractTracked.trackAdding(AbstractTracked.java:256) > at > org.osgi.util.tracker.AbstractTracked.track(AbstractTracked.java:229) > at > org.osgi.util.tracker.ServiceTracker$Tracked.serviceChanged(ServiceTracker.java:901) > at > org.apache.felix.framework.util.EventDispatcher.invokeServiceListenerCallback(EventDispatcher.java:991) > at > org.apache.felix.framework.util.EventDispatcher.fireEventImmediately(EventDispatcher.java:839) > at > org.apache.felix.framework.util.EventDispatcher.fireServiceEvent(EventDispatcher.java:546) > at org.apache.felix.framework.Felix.fireServiceEvent(Felix.java:4557) > at org.apache.felix.framework.Felix.registerService(Felix.java:3549) > at > org.apache.felix.framework.BundleContextImpl.registerService(BundleContextImpl.java:348) > at > org.apache.aries.blueprint.container.BlueprintContainerImpl.registerService(BlueprintContainerImpl.java:459) > at > org.apache.aries.blueprint.container.ServiceRecipe.register(ServiceRecipe.java:193) > at > org.apache.aries.blueprint.container.BlueprintContainerImpl.registerServices(BlueprintContainerImpl.java:710) > at > org.apache.aries.blueprint.container.BlueprintContainerImpl.doRun(BlueprintContainerImpl.java:385) > at > org.apache.aries.blueprint.container.BlueprintContainerImpl.run(BlueprintContainerImpl.java:270) > at > java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) > at java.util.concurrent.FutureTask.run(FutureTask.java:262) > at > org.apache.aries.blueprint.container.ExecutorServiceWrapper.run(ExecutorServiceWrapper.java:106) > at > org.apache.aries.blueprint.utils.threading.impl.DiscardableRunnable.run(DiscardableRunnable.java:48) > at > java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) > at java.util.concurrent.FutureTask.run(FutureTask.java:262) > at > java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:178) > at > java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:292) > at > java.util.concurrent.ThreadPoolExecutor.runW
[jira] [Resolved] (ARIES-1433) Persistence units are not picked up while bundle is in status resolved
[ https://issues.apache.org/jira/browse/ARIES-1433?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schneider resolved ARIES-1433. Resolution: Won't Fix We can not add the services when the bundle is in state resolved. Interestingly the case of a combined bundle with persistence unit and consumers of the EntityManager services seems to work. So this is not a big issue. See https://github.com/cschneider/jpa.blueprint.test > Persistence units are not picked up while bundle is in status resolved > -- > > Key: ARIES-1433 > URL: https://issues.apache.org/jira/browse/ARIES-1433 > Project: Aries > Issue Type: Bug > Components: JPA >Affects Versions: jpa-2.2.0 > Reporter: Christian Schneider > Assignee: Christian Schneider > Fix For: jpa-2.3.0 > > > Currently the PersistenceBundleTracker only watches bundle in state > Bundle.STARTING | Bundle.ACTIVE. > So if you put a persistence unit definition and a blueprint JPA bean using > the persistence unit into the same bundle then it will never start. > We should also track bundles in state resolved. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (ARIES-1454) NPE in TxInterceptor
[
https://issues.apache.org/jira/browse/ARIES-1454?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christian Schneider resolved ARIES-1454.
Resolution: Fixed
I fixed it in this commit:
https://github.com/apache/aries/commit/628523f8c990ab7dc9bb302567a497d60c3fd011
This avoids the NPE. Additionally I upgrade the Coordinator version in karaf.
> NPE in TxInterceptor
>
>
> Key: ARIES-1454
> URL: https://issues.apache.org/jira/browse/ARIES-1454
> Project: Aries
> Issue Type: Bug
> Components: Transaction
>Affects Versions: transaction-blueprint-1.1.1
> Environment: Karaf 4.0.2 (Felix)
> JPA (Hibernate)
>Reporter: Mohammad Shamsi
> Assignee: Christian Schneider
> Fix For: transaction-3.0.0
>
>
> I am running some load tests agains an osgi app, which is running inside
> karaf 4.0.2, using Aries Blueprint and JPA (Hibernate) .
> The test is using multiple threads (10) to issue some random calls to the
> application.
> Sometimes, randomly, some of the call throwing NPE in TxInterceptor:
> {code:java}
> java.lang.NullPointerException
> at
> org.apache.aries.transaction.TxInterceptorImpl.postCallWithReturn(TxInterceptorImpl.java:101)[66:org.apache.aries.transaction.blueprint:1.1.1]
> at
> org.apache.aries.blueprint.proxy.SingleInterceptorCollaborator.postInvoke(SingleInterceptorCollaborator.java:75)[48:org.apache.aries.blueprint.core:1.4.4]
> at Proxy65968de8_a064_4203_9a53_5f0c8e536279.lockAll(Unknown
> Source)[:]
> {code}
> The NPE is thrown from "postCallWithReturn" and "postCallWithException" in
> following line:
> {code:java}
> token.getCoordination().end();
> {code}
> The "getCoordination()" call in above line is returning null.
> As I mentioned, it is happening from time to time. sometimes after 20 mins,
> sometimes after hours of test execution and it is happening in different
> transactional methods in different classes of the application.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (ARIES-1457) Custom interceptor prohibits declarative transactions
[ https://issues.apache.org/jira/browse/ARIES-1457?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schneider resolved ARIES-1457. Resolution: Invalid Assignee: Christian Schneider See linked karaf issue for details. > Custom interceptor prohibits declarative transactions > - > > Key: ARIES-1457 > URL: https://issues.apache.org/jira/browse/ARIES-1457 > Project: Aries > Issue Type: Bug > Components: Blueprint, Transaction >Affects Versions: blueprint-core-1.4.5, transaction-blueprint-2.0.0 > Environment: Karaf 4.0.3, Windows 7 x64, Oracle JDK 1.8 >Reporter: Felix Wassmer > Assignee: Christian Schneider > > When using declarative transactions in Karaf 4 (Aries transaction blueprint > 2.0.0), > adding a custom interceptor seems to conflict with the aries TxInterceptor. > Expected behavior > Interceptor enabled for service A > Service A with TxType.REQUIRED calls service B with TxType.MANDATORY and > service B will be executed in a transaction. > Actual behavior > Service B throws exception: No transaction present when calling method that > mandates a transaction. > (TxInterceptor was not registered for service A and therefore no tx started) > Disabling the interceptor (removing declaration in blueprint), > transactional behaviour works as expected (B is executed in a transaction). > Custom interceptor + tx behavior works as expected when using transaction > blueprint 1.1.1 and delcaring transactions in blueprint. > Example to reproduce the issue: > https://github.com/fwassmer/transaction-chain/ -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (ARIES-1472) Precautions to avoid influencing other processors
Christian Schneider created ARIES-1472: -- Summary: Precautions to avoid influencing other processors Key: ARIES-1472 URL: https://issues.apache.org/jira/browse/ARIES-1472 Project: Aries Issue Type: Bug Components: Blueprint Affects Versions: blueprint-maven-plugin-1.2.0 Reporter: Christian Schneider Assignee: Christian Schneider Fix For: blueprint-maven-plugin-1.3.0 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (ARIES-1472) Precautions to avoid influencing other processors
[ https://issues.apache.org/jira/browse/ARIES-1472?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schneider updated ARIES-1472: --- Fix Version/s: (was: blueprint-maven-plugin-1.3.0) > Precautions to avoid influencing other processors > - > > Key: ARIES-1472 > URL: https://issues.apache.org/jira/browse/ARIES-1472 > Project: Aries > Issue Type: Bug > Components: Blueprint >Affects Versions: blueprint-maven-plugin-1.2.0 > Reporter: Christian Schneider >Assignee: Christian Schneider > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (ARIES-1472) Precautions to avoid influencing other processors
[ https://issues.apache.org/jira/browse/ARIES-1472?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schneider updated ARIES-1472: --- Fix Version/s: blueprint-authz-1.0.1 > Precautions to avoid influencing other processors > - > > Key: ARIES-1472 > URL: https://issues.apache.org/jira/browse/ARIES-1472 > Project: Aries > Issue Type: Bug > Components: Blueprint >Affects Versions: blueprint-authz-1.0.0 > Reporter: Christian Schneider >Assignee: Christian Schneider > Fix For: blueprint-authz-1.0.1 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (ARIES-1472) Precautions to avoid influencing other processors
[ https://issues.apache.org/jira/browse/ARIES-1472?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schneider resolved ARIES-1472. Resolution: Fixed > Precautions to avoid influencing other processors > - > > Key: ARIES-1472 > URL: https://issues.apache.org/jira/browse/ARIES-1472 > Project: Aries > Issue Type: Bug > Components: Blueprint >Affects Versions: blueprint-authz-1.0.0 > Reporter: Christian Schneider >Assignee: Christian Schneider > Fix For: blueprint-authz-1.0.1 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (ARIES-1472) Precautions to avoid influencing other processors
[ https://issues.apache.org/jira/browse/ARIES-1472?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schneider updated ARIES-1472: --- Affects Version/s: (was: blueprint-maven-plugin-1.2.0) blueprint-authz-1.0.0 > Precautions to avoid influencing other processors > - > > Key: ARIES-1472 > URL: https://issues.apache.org/jira/browse/ARIES-1472 > Project: Aries > Issue Type: Bug > Components: Blueprint >Affects Versions: blueprint-authz-1.0.0 > Reporter: Christian Schneider >Assignee: Christian Schneider > Fix For: blueprint-authz-1.0.1 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (ARIES-1472) Precautions to avoid influencing other processors
[ https://issues.apache.org/jira/browse/ARIES-1472?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15052406#comment-15052406 ] Christian Schneider commented on ARIES-1472: https://github.com/apache/aries/commit/95766a2c06a5fc7aa3627defe84fcb43da505562 > Precautions to avoid influencing other processors > - > > Key: ARIES-1472 > URL: https://issues.apache.org/jira/browse/ARIES-1472 > Project: Aries > Issue Type: Bug > Components: Blueprint >Affects Versions: blueprint-authz-1.0.0 > Reporter: Christian Schneider >Assignee: Christian Schneider > Fix For: blueprint-authz-1.0.1 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (ARIES-1450) Cache computation of effective txType
[ https://issues.apache.org/jira/browse/ARIES-1450?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schneider updated ARIES-1450: --- Fix Version/s: (was: transaction-3.0.0) transaction-blueprint-2.1.0 > Cache computation of effective txType > - > > Key: ARIES-1450 > URL: https://issues.apache.org/jira/browse/ARIES-1450 > Project: Aries > Issue Type: Improvement > Components: Transaction >Affects Versions: transaction-blueprint-2.0.0 > Reporter: Christian Schneider >Assignee: Christian Schneider > Fix For: transaction-blueprint-2.1.0 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (ARIES-1380) Remove remaining NLS usage
[ https://issues.apache.org/jira/browse/ARIES-1380?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schneider updated ARIES-1380: --- Fix Version/s: (was: transaction-3.0.0) transaction-blueprint-2.1.0 > Remove remaining NLS usage > -- > > Key: ARIES-1380 > URL: https://issues.apache.org/jira/browse/ARIES-1380 > Project: Aries > Issue Type: Improvement > Components: Transaction >Affects Versions: transaction-blueprint-1.1.1 > Reporter: Christian Schneider >Assignee: Christian Schneider > Fix For: transaction-blueprint-2.1.0 > > > Most of the exceptions and log messages do not use NLS support. Remove the > rest to unify the handling. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (ARIES-1454) NPE in TxInterceptor
[
https://issues.apache.org/jira/browse/ARIES-1454?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christian Schneider updated ARIES-1454:
---
Fix Version/s: (was: transaction-3.0.0)
transaction-blueprint-2.1.0
> NPE in TxInterceptor
>
>
> Key: ARIES-1454
> URL: https://issues.apache.org/jira/browse/ARIES-1454
> Project: Aries
> Issue Type: Bug
> Components: Transaction
>Affects Versions: transaction-blueprint-1.1.1
> Environment: Karaf 4.0.2 (Felix)
> JPA (Hibernate)
>Reporter: Mohammad Shamsi
> Assignee: Christian Schneider
> Fix For: transaction-blueprint-2.1.0
>
>
> I am running some load tests agains an osgi app, which is running inside
> karaf 4.0.2, using Aries Blueprint and JPA (Hibernate) .
> The test is using multiple threads (10) to issue some random calls to the
> application.
> Sometimes, randomly, some of the call throwing NPE in TxInterceptor:
> {code:java}
> java.lang.NullPointerException
> at
> org.apache.aries.transaction.TxInterceptorImpl.postCallWithReturn(TxInterceptorImpl.java:101)[66:org.apache.aries.transaction.blueprint:1.1.1]
> at
> org.apache.aries.blueprint.proxy.SingleInterceptorCollaborator.postInvoke(SingleInterceptorCollaborator.java:75)[48:org.apache.aries.blueprint.core:1.4.4]
> at Proxy65968de8_a064_4203_9a53_5f0c8e536279.lockAll(Unknown
> Source)[:]
> {code}
> The NPE is thrown from "postCallWithReturn" and "postCallWithException" in
> following line:
> {code:java}
> token.getCoordination().end();
> {code}
> The "getCoordination()" call in above line is returning null.
> As I mentioned, it is happening from time to time. sometimes after 20 mins,
> sometimes after hours of test execution and it is happening in different
> transactional methods in different classes of the application.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (ARIES-1464) Improve blueprint-maven-plugin: add prototype-scope support
[
https://issues.apache.org/jira/browse/ARIES-1464?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christian Schneider updated ARIES-1464:
---
Fix Version/s: blueprint-maven-plugin-1.3.0
> Improve blueprint-maven-plugin: add prototype-scope support
> ---
>
> Key: ARIES-1464
> URL: https://issues.apache.org/jira/browse/ARIES-1464
> Project: Aries
> Issue Type: Improvement
> Components: Blueprint
>Reporter: Sam Wright
> Assignee: Christian Schneider
> Fix For: blueprint-maven-plugin-1.3.0
>
>
> -I propose adding support for configuring bean scope using
> blueprint-maven-plugin, e.g. annotating a class with `@Scope("prototype")`
> will add `scope = "prototype"` to the bean's xml element.-
> The JSR-330 spec says that a class can be defined as a prototype-scoped bean
> by applying only the @Named annotation, and that to give the bean a
> singleton-scope the @Singleton annotation should then be applied (either with
> or replacing @Named), e.g.
> {code}
> @Singleton class AutonamedSingleton {}
> @Singleton @Named("foo") class NamedSingleton {}
> @Named AutonamedPrototype {}
> @Named("bar") NamedPrototype {}
> {code}
> The pull request implements this. NB this maintains backwards-compatibility
> with classes annotated using @Singleton or @Component, with or without @Named.
> [~ch...@die-schneider.net] is probably the person to review this.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (ARIES-1464) Improve blueprint-maven-plugin: add prototype-scope support
[
https://issues.apache.org/jira/browse/ARIES-1464?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15052687#comment-15052687
]
Christian Schneider commented on ARIES-1464:
Many thanks. Will look into it today.
> Improve blueprint-maven-plugin: add prototype-scope support
> ---
>
> Key: ARIES-1464
> URL: https://issues.apache.org/jira/browse/ARIES-1464
> Project: Aries
> Issue Type: Improvement
> Components: Blueprint
>Reporter: Sam Wright
> Assignee: Christian Schneider
> Fix For: blueprint-maven-plugin-1.3.0
>
>
> -I propose adding support for configuring bean scope using
> blueprint-maven-plugin, e.g. annotating a class with `@Scope("prototype")`
> will add `scope = "prototype"` to the bean's xml element.-
> The JSR-330 spec says that a class can be defined as a prototype-scoped bean
> by applying only the @Named annotation, and that to give the bean a
> singleton-scope the @Singleton annotation should then be applied (either with
> or replacing @Named), e.g.
> {code}
> @Singleton class AutonamedSingleton {}
> @Singleton @Named("foo") class NamedSingleton {}
> @Named AutonamedPrototype {}
> @Named("bar") NamedPrototype {}
> {code}
> The pull request implements this. NB this maintains backwards-compatibility
> with classes annotated using @Singleton or @Component, with or without @Named.
> [~ch...@die-schneider.net] is probably the person to review this.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (ARIES-1464) Improve blueprint-maven-plugin: add prototype-scope support
[
https://issues.apache.org/jira/browse/ARIES-1464?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15052820#comment-15052820
]
Christian Schneider commented on ARIES-1464:
The code looks good. Can you point me to where the spec defines this. I would
like to make sure we follow the spec as well as possible.
> Improve blueprint-maven-plugin: add prototype-scope support
> ---
>
> Key: ARIES-1464
> URL: https://issues.apache.org/jira/browse/ARIES-1464
> Project: Aries
> Issue Type: Improvement
> Components: Blueprint
>Reporter: Sam Wright
> Assignee: Christian Schneider
> Fix For: blueprint-maven-plugin-1.3.0
>
>
> -I propose adding support for configuring bean scope using
> blueprint-maven-plugin, e.g. annotating a class with `@Scope("prototype")`
> will add `scope = "prototype"` to the bean's xml element.-
> The JSR-330 spec says that a class can be defined as a prototype-scoped bean
> by applying only the @Named annotation, and that to give the bean a
> singleton-scope the @Singleton annotation should then be applied (either with
> or replacing @Named), e.g.
> {code}
> @Singleton class AutonamedSingleton {}
> @Singleton @Named("foo") class NamedSingleton {}
> @Named AutonamedPrototype {}
> @Named("bar") NamedPrototype {}
> {code}
> The pull request implements this. NB this maintains backwards-compatibility
> with classes annotated using @Singleton or @Component, with or without @Named.
> [~ch...@die-schneider.net] is probably the person to review this.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (ARIES-1432) EMFTracker getTransactionType() method always returns PersistenceUnitTransactionType.JTA
[ https://issues.apache.org/jira/browse/ARIES-1432?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15052834#comment-15052834 ] Christian Schneider commented on ARIES-1432: Any news about this one? You mentioned you were making progress. > EMFTracker getTransactionType() method always returns > PersistenceUnitTransactionType.JTA > > > Key: ARIES-1432 > URL: https://issues.apache.org/jira/browse/ARIES-1432 > Project: Aries > Issue Type: Bug > Components: JPA >Affects Versions: jpa-2.1.0, jpa-2.3.0 >Reporter: Tim >Priority: Minor > > It looks as though the EMFTracker getTransactionType() method is not working > correctly, it always returns a PersistenceUnitTransactionType.JTA regardless > of the transaction-type (JTA or RESOURCE_LOCAL). Consequently the > ResourceLocalJpaTemplate is never instantiated if RESOURCE_LOCAL is specified > in the persistence.xml. > I could probably help if I knew where/why the logic for retrieving the > PersistenceUnitTransactionType from the properties of the > EntityManagerFactory came from? > The bundles I installed were > feature:install scr > feature:install jpa/2.1.0 > feature:install hibernate/4.3.6.Final > feature:repo-add mvn:org.ops4j.pax.jdbc/pax-jdbc-features/0.7.0/xml/features > feature:install pax-jdbc-h2 > feature:install transaction > feature:install pax-jdbc-pool-dbcp2 > feature:install pax-jdbc-config > service:list javax.sql.DataSource > bundle:install -s mvn:net.lr.tasklist.ds/tasklist-model/1.0.0-SNAPSHOT > bundle:install -s mvn:net.lr.tasklist.ds/tasklist-persistence/1.0.0-SNAPSHOT > feature:install http-whiteboard > feature:install persistence-api > bundle:install -s mvn:net.lr.tasklist.ds/tasklist-ui/1.0.0-SNAPSHOT > with a config > osgi.jdbc.driver.name=H2-pool > url=jdbc:h2:mem:test > user=sa > password= > dataSourceName=tasklist > 1) If the transaction-type="JTA" in persistence.xml (even though > osgi.jdbc.driver.name=H2-pool) the tasklist tests will appear to work e.g. > another task can be saved. However I modified the test to insert 2 tasks > within one lambda expression and throw a Runtime exception after the first > task insertion, expected result would be that the first insertion is rolled > back, however it was committed. > 2) If the transaction-type="RESOURCE_LOCAL" in persistence.xml the following > exception is thrown (note the presence of XAJpaTemplate rather than > ResourceLocalJpaTemplate) > java.lang.RuntimeException: java.lang.RuntimeException: > javax.persistence.TransactionRequiredException: no transaction is in progress > at > org.apache.aries.jpa.support.impl.XAJpaTemplate.txExpr(XAJpaTemplate.java:62) > at > org.apache.aries.jpa.support.impl.AbstractJpaTemplate.tx(AbstractJpaTemplate.java:32) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (ARIES-1464) Improve blueprint-maven-plugin: add prototype-scope support
[
https://issues.apache.org/jira/browse/ARIES-1464?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15052837#comment-15052837
]
Christian Schneider commented on ARIES-1464:
Sounds good. I also found a lot of other mentions of this behaviour. So I will
commit this.
> Improve blueprint-maven-plugin: add prototype-scope support
> ---
>
> Key: ARIES-1464
> URL: https://issues.apache.org/jira/browse/ARIES-1464
> Project: Aries
> Issue Type: Improvement
> Components: Blueprint
>Reporter: Sam Wright
> Assignee: Christian Schneider
> Fix For: blueprint-maven-plugin-1.3.0
>
>
> -I propose adding support for configuring bean scope using
> blueprint-maven-plugin, e.g. annotating a class with `@Scope("prototype")`
> will add `scope = "prototype"` to the bean's xml element.-
> The JSR-330 spec says that a class can be defined as a prototype-scoped bean
> by applying only the @Named annotation, and that to give the bean a
> singleton-scope the @Singleton annotation should then be applied (either with
> or replacing @Named), e.g.
> {code}
> @Singleton class AutonamedSingleton {}
> @Singleton @Named("foo") class NamedSingleton {}
> @Named AutonamedPrototype {}
> @Named("bar") NamedPrototype {}
> {code}
> The pull request implements this. NB this maintains backwards-compatibility
> with classes annotated using @Singleton or @Component, with or without @Named.
> [~ch...@die-schneider.net] is probably the person to review this.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (ARIES-1464) Improve blueprint-maven-plugin: add prototype-scope support
[
https://issues.apache.org/jira/browse/ARIES-1464?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christian Schneider resolved ARIES-1464.
Resolution: Fixed
> Improve blueprint-maven-plugin: add prototype-scope support
> ---
>
> Key: ARIES-1464
> URL: https://issues.apache.org/jira/browse/ARIES-1464
> Project: Aries
> Issue Type: Improvement
> Components: Blueprint
>Reporter: Sam Wright
> Assignee: Christian Schneider
> Fix For: blueprint-maven-plugin-1.3.0
>
>
> -I propose adding support for configuring bean scope using
> blueprint-maven-plugin, e.g. annotating a class with `@Scope("prototype")`
> will add `scope = "prototype"` to the bean's xml element.-
> The JSR-330 spec says that a class can be defined as a prototype-scoped bean
> by applying only the @Named annotation, and that to give the bean a
> singleton-scope the @Singleton annotation should then be applied (either with
> or replacing @Named), e.g.
> {code}
> @Singleton class AutonamedSingleton {}
> @Singleton @Named("foo") class NamedSingleton {}
> @Named AutonamedPrototype {}
> @Named("bar") NamedPrototype {}
> {code}
> The pull request implements this. NB this maintains backwards-compatibility
> with classes annotated using @Singleton or @Component, with or without @Named.
> [~ch...@die-schneider.net] is probably the person to review this.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (ARIES-1464) Improve blueprint-maven-plugin: add prototype-scope support
[
https://issues.apache.org/jira/browse/ARIES-1464?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15052851#comment-15052851
]
Christian Schneider commented on ARIES-1464:
You are lucky with the timing. I plan to do the release tomorrow.
So I would appreciate if you could run some tests to verify all is fine.
> Improve blueprint-maven-plugin: add prototype-scope support
> ---
>
> Key: ARIES-1464
> URL: https://issues.apache.org/jira/browse/ARIES-1464
> Project: Aries
> Issue Type: Improvement
> Components: Blueprint
>Reporter: Sam Wright
> Assignee: Christian Schneider
> Fix For: blueprint-maven-plugin-1.3.0
>
>
> -I propose adding support for configuring bean scope using
> blueprint-maven-plugin, e.g. annotating a class with `@Scope("prototype")`
> will add `scope = "prototype"` to the bean's xml element.-
> The JSR-330 spec says that a class can be defined as a prototype-scoped bean
> by applying only the @Named annotation, and that to give the bean a
> singleton-scope the @Singleton annotation should then be applied (either with
> or replacing @Named), e.g.
> {code}
> @Singleton class AutonamedSingleton {}
> @Singleton @Named("foo") class NamedSingleton {}
> @Named AutonamedPrototype {}
> @Named("bar") NamedPrototype {}
> {code}
> The pull request implements this. NB this maintains backwards-compatibility
> with classes annotated using @Singleton or @Component, with or without @Named.
> [~ch...@die-schneider.net] is probably the person to review this.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (ARIES-1473) Aries JPA creates derby.log outside target
Christian Schneider created ARIES-1473: -- Summary: Aries JPA creates derby.log outside target Key: ARIES-1473 URL: https://issues.apache.org/jira/browse/ARIES-1473 Project: Aries Issue Type: Bug Components: JPA Affects Versions: jpa-2.2.0 Reporter: Christian Schneider Assignee: Christian Schneider Fix For: jpa-2.3.0 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (ARIES-1473) Aries JPA creates derby.log outside target
[ https://issues.apache.org/jira/browse/ARIES-1473?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schneider resolved ARIES-1473. Resolution: Fixed > Aries JPA creates derby.log outside target > -- > > Key: ARIES-1473 > URL: https://issues.apache.org/jira/browse/ARIES-1473 > Project: Aries > Issue Type: Bug > Components: JPA >Affects Versions: jpa-2.2.0 > Reporter: Christian Schneider >Assignee: Christian Schneider > Fix For: jpa-2.3.0 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (ARIES-1464) Improve blueprint-maven-plugin: add prototype-scope support
[
https://issues.apache.org/jira/browse/ARIES-1464?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15054391#comment-15054391
]
Christian Schneider commented on ARIES-1464:
Can you open a new issue for the init/destroy problem with some description how
to reproduce?
Not sure about @Transactional. For Aries transaction > 1.3.0 and 2.0.0 the
transactions are processed at runtime. So the plugin does not need to do
anything.
> Improve blueprint-maven-plugin: add prototype-scope support
> ---
>
> Key: ARIES-1464
> URL: https://issues.apache.org/jira/browse/ARIES-1464
> Project: Aries
> Issue Type: Improvement
> Components: Blueprint
>Reporter: Sam Wright
>Assignee: Christian Schneider
> Fix For: blueprint-maven-plugin-1.3.0
>
>
> -I propose adding support for configuring bean scope using
> blueprint-maven-plugin, e.g. annotating a class with `@Scope("prototype")`
> will add `scope = "prototype"` to the bean's xml element.-
> The JSR-330 spec says that a class can be defined as a prototype-scoped bean
> by applying only the @Named annotation, and that to give the bean a
> singleton-scope the @Singleton annotation should then be applied (either with
> or replacing @Named), e.g.
> {code}
> @Singleton class AutonamedSingleton {}
> @Singleton @Named("foo") class NamedSingleton {}
> @Named AutonamedPrototype {}
> @Named("bar") NamedPrototype {}
> {code}
> The pull request implements this. NB this maintains backwards-compatibility
> with classes annotated using @Singleton or @Component, with or without @Named.
> [~ch...@die-schneider.net] is probably the person to review this.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (ARIES-1474) blueprint-maven-plugin: Inherited init/destroy methods are ignored
[
https://issues.apache.org/jira/browse/ARIES-1474?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15054562#comment-15054562
]
Christian Schneider commented on ARIES-1474:
I think before doing changes we need to first have a common understanding of
the rules to be in place. This is from JSR-250 Chapter 2.1:
1. Class-level annotations only affect the class they annotate and their
members, that is, its methods and fields. They never affect a member declared
by a superclass, even if it is not hidden or overridden by the class in
question.
2. In addition to affecting the annotated class, class-level annotations may
act as a shorthand for member-level annotations. If a member carries a specific
memberlevel
annotation, any annotations of the same type implied by a class-level
annotation are ignored. In other words, explicit member-level annotations have
priority over member-level annotations implied by a class-level annotation. For
example, @WebService annotation on a class implies that all the public methods
in the class that it is applied on are annotated with @WebMethod if there is no
@WebMethod annotation on any of the methods. However if there is a @WebMethod
annotation on any method then the @WebService does not imply the presence of
@WebMethod on the other public methods in the class.
3. The interfaces implemented by a class never contribute annotations to the
class itself or any of its members.
4. Members inherited from a superclass and which are not hidden or overridden
maintain the annotations they had in the class that declared them, including
member-level annotations implied by class-level ones.
5. Member-level annotations on a hidden or overridden member are always ignored
As far as I understood these rules also apply to what we do.
So one immediate change I see from these rules is that we need to ignore
annotations from interfaces.
About your example the expectation would be that for class C:
destroy="destroy" and init is not set.
Is that asumption correct?
> blueprint-maven-plugin: Inherited init/destroy methods are ignored
> --
>
> Key: ARIES-1474
> URL: https://issues.apache.org/jira/browse/ARIES-1474
> Project: Aries
> Issue Type: Bug
> Components: Blueprint
>Reporter: Sam Wright
>
> Current behaviour:
> {code}
> public class A {
> @PostConstruct
> public void init() {}
> @PreDestroy
> public void destroy() {}
> }
> public class B extends A {}
> public class C extends B {
> @Override
> public void init() {}
> @PostConstruct
> public void secondInit()
> }
> {code}
> Three problems:
> * The A.destroy() method is ignored
> * The C.init() method overrides A.init() without the @PostConstruct
> annotation, but is still taken to be the init method. This means the subclass
> can't disable a superclass' init method.
> * The C.secondInit() method is silently ignored because another init method
> is found first.
> Patch incoming...
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (ARIES-1474) blueprint-maven-plugin: Inherited init/destroy methods are ignored
[
https://issues.apache.org/jira/browse/ARIES-1474?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15054885#comment-15054885
]
Christian Schneider commented on ARIES-1474:
Oops .. yes . You are correct. The init method should be secondInit I just
looked at the overriden init.
I am not yet sure how much we can predict all cases at the moment. So I tend to
do the release without the new changes. The current code on trunk is clearly
not correct but at least
it is the same as before.
If we do a release in about a month or two we have a bit more time to check it
all works like expected. What do you think?
> blueprint-maven-plugin: Inherited init/destroy methods are ignored
> --
>
> Key: ARIES-1474
> URL: https://issues.apache.org/jira/browse/ARIES-1474
> Project: Aries
> Issue Type: Bug
> Components: Blueprint
>Reporter: Sam Wright
>
> Current behaviour:
> {code}
> public class A {
> @PostConstruct
> public void init() {}
> @PreDestroy
> public void destroy() {}
> }
> public class B extends A {}
> public class C extends B {
> @Override
> public void init() {}
> @PostConstruct
> public void secondInit()
> }
> {code}
> Three problems:
> * The A.destroy() method is ignored
> * The C.init() method overrides A.init() without the @PostConstruct
> annotation, but is still taken to be the init method. This means the subclass
> can't disable a superclass' init method.
> * The C.secondInit() method is silently ignored because another init method
> is found first.
> Patch incoming...
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (ARIES-1476) blueprint-maven-plugin: support 0 or multiple OsgiServiceProvider#classes
[
https://issues.apache.org/jira/browse/ARIES-1476?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christian Schneider updated ARIES-1476:
---
Affects Version/s: blueprint-maven-plugin-1.3.0
> blueprint-maven-plugin: support 0 or multiple OsgiServiceProvider#classes
> -
>
> Key: ARIES-1476
> URL: https://issues.apache.org/jira/browse/ARIES-1476
> Project: Aries
> Issue Type: Improvement
> Components: Blueprint
>Affects Versions: blueprint-maven-plugin-1.3.0
>Reporter: Sam Wright
> Fix For: blueprint-maven-plugin-1.4.0
>
>
> Currently blueprint-maven-plugin supports annotating beans with
> @OsgiServiceProvider(classes = ...) to expose the bean as an OSGi service,
> but only when given exactly 1 interface class to expose it under.
> This improvement adds support for passing 0 classes, which creates:
> {code}
>
> {code}
> and also adds support for passing multiple classes, which creates:
> {code}
>
>
> com.example.ServiceA
> com.example.ServiceB
>
>
> {code}
> Patch incoming...
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (ARIES-1476) blueprint-maven-plugin: support 0 or multiple OsgiServiceProvider#classes
[
https://issues.apache.org/jira/browse/ARIES-1476?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christian Schneider updated ARIES-1476:
---
Fix Version/s: blueprint-maven-plugin-1.4.0
> blueprint-maven-plugin: support 0 or multiple OsgiServiceProvider#classes
> -
>
> Key: ARIES-1476
> URL: https://issues.apache.org/jira/browse/ARIES-1476
> Project: Aries
> Issue Type: Improvement
> Components: Blueprint
>Affects Versions: blueprint-maven-plugin-1.3.0
>Reporter: Sam Wright
> Fix For: blueprint-maven-plugin-1.4.0
>
>
> Currently blueprint-maven-plugin supports annotating beans with
> @OsgiServiceProvider(classes = ...) to expose the bean as an OSGi service,
> but only when given exactly 1 interface class to expose it under.
> This improvement adds support for passing 0 classes, which creates:
> {code}
>
> {code}
> and also adds support for passing multiple classes, which creates:
> {code}
>
>
> com.example.ServiceA
> com.example.ServiceB
>
>
> {code}
> Patch incoming...
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (ARIES-1474) blueprint-maven-plugin: Inherited init/destroy methods are ignored
[
https://issues.apache.org/jira/browse/ARIES-1474?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christian Schneider updated ARIES-1474:
---
Affects Version/s: blueprint-maven-plugin-1.3.0
> blueprint-maven-plugin: Inherited init/destroy methods are ignored
> --
>
> Key: ARIES-1474
> URL: https://issues.apache.org/jira/browse/ARIES-1474
> Project: Aries
> Issue Type: Bug
> Components: Blueprint
>Affects Versions: blueprint-maven-plugin-1.3.0
>Reporter: Sam Wright
> Fix For: blueprint-maven-plugin-1.4.0
>
>
> Current behaviour:
> {code}
> public class A {
> @PostConstruct
> public void init() {}
> @PreDestroy
> public void destroy() {}
> }
> public class B extends A {}
> public class C extends B {
> @Override
> public void init() {}
> @PostConstruct
> public void secondInit()
> }
> {code}
> Three problems:
> * The A.destroy() method is ignored
> * The C.init() method overrides A.init() without the @PostConstruct
> annotation, but is still taken to be the init method. This means the subclass
> can't disable a superclass' init method.
> * The C.secondInit() method is silently ignored because another init method
> is found first.
> Patch incoming...
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (ARIES-1475) blueprint-maven-plugin: support methods annotated with @Transactional
[ https://issues.apache.org/jira/browse/ARIES-1475?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schneider updated ARIES-1475: --- Fix Version/s: blueprint-maven-plugin-1.4.0 > blueprint-maven-plugin: support methods annotated with @Transactional > - > > Key: ARIES-1475 > URL: https://issues.apache.org/jira/browse/ARIES-1475 > Project: Aries > Issue Type: Improvement > Components: Blueprint >Affects Versions: blueprint-maven-plugin-1.3.0 >Reporter: Sam Wright > Fix For: blueprint-maven-plugin-1.4.0 > > > Currently @Transactional is only supported when annotating a class. Blueprint > supports specifying the transactional type for all methods and/or for > individual methods by adding more elements. > Patch incoming... -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (ARIES-1474) blueprint-maven-plugin: Inherited init/destroy methods are ignored
[
https://issues.apache.org/jira/browse/ARIES-1474?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christian Schneider updated ARIES-1474:
---
Fix Version/s: blueprint-maven-plugin-1.4.0
> blueprint-maven-plugin: Inherited init/destroy methods are ignored
> --
>
> Key: ARIES-1474
> URL: https://issues.apache.org/jira/browse/ARIES-1474
> Project: Aries
> Issue Type: Bug
> Components: Blueprint
>Affects Versions: blueprint-maven-plugin-1.3.0
>Reporter: Sam Wright
> Fix For: blueprint-maven-plugin-1.4.0
>
>
> Current behaviour:
> {code}
> public class A {
> @PostConstruct
> public void init() {}
> @PreDestroy
> public void destroy() {}
> }
> public class B extends A {}
> public class C extends B {
> @Override
> public void init() {}
> @PostConstruct
> public void secondInit()
> }
> {code}
> Three problems:
> * The A.destroy() method is ignored
> * The C.init() method overrides A.init() without the @PostConstruct
> annotation, but is still taken to be the init method. This means the subclass
> can't disable a superclass' init method.
> * The C.secondInit() method is silently ignored because another init method
> is found first.
> Patch incoming...
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (ARIES-1475) blueprint-maven-plugin: support methods annotated with @Transactional
[ https://issues.apache.org/jira/browse/ARIES-1475?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schneider updated ARIES-1475: --- Affects Version/s: blueprint-maven-plugin-1.3.0 > blueprint-maven-plugin: support methods annotated with @Transactional > - > > Key: ARIES-1475 > URL: https://issues.apache.org/jira/browse/ARIES-1475 > Project: Aries > Issue Type: Improvement > Components: Blueprint >Affects Versions: blueprint-maven-plugin-1.3.0 >Reporter: Sam Wright > Fix For: blueprint-maven-plugin-1.4.0 > > > Currently @Transactional is only supported when annotating a class. Blueprint > supports specifying the transactional type for all methods and/or for > individual methods by adding more elements. > Patch incoming... -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (ARIES-1476) blueprint-maven-plugin: support 0 or multiple OsgiServiceProvider#classes
[
https://issues.apache.org/jira/browse/ARIES-1476?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christian Schneider reassigned ARIES-1476:
--
Assignee: Christian Schneider
> blueprint-maven-plugin: support 0 or multiple OsgiServiceProvider#classes
> -
>
> Key: ARIES-1476
> URL: https://issues.apache.org/jira/browse/ARIES-1476
> Project: Aries
> Issue Type: Improvement
> Components: Blueprint
>Affects Versions: blueprint-maven-plugin-1.3.0
>Reporter: Sam Wright
>Assignee: Christian Schneider
> Fix For: blueprint-maven-plugin-1.4.0
>
>
> Currently blueprint-maven-plugin supports annotating beans with
> @OsgiServiceProvider(classes = ...) to expose the bean as an OSGi service,
> but only when given exactly 1 interface class to expose it under.
> This improvement adds support for passing 0 classes, which creates:
> {code}
>
> {code}
> and also adds support for passing multiple classes, which creates:
> {code}
>
>
> com.example.ServiceA
> com.example.ServiceB
>
>
> {code}
> Patch incoming...
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (ARIES-1475) blueprint-maven-plugin: support methods annotated with @Transactional
[ https://issues.apache.org/jira/browse/ARIES-1475?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schneider reassigned ARIES-1475: -- Assignee: Christian Schneider > blueprint-maven-plugin: support methods annotated with @Transactional > - > > Key: ARIES-1475 > URL: https://issues.apache.org/jira/browse/ARIES-1475 > Project: Aries > Issue Type: Improvement > Components: Blueprint >Affects Versions: blueprint-maven-plugin-1.3.0 >Reporter: Sam Wright >Assignee: Christian Schneider > Fix For: blueprint-maven-plugin-1.4.0 > > > Currently @Transactional is only supported when annotating a class. Blueprint > supports specifying the transactional type for all methods and/or for > individual methods by adding more elements. > Patch incoming... -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (ARIES-1474) blueprint-maven-plugin: Inherited init/destroy methods are ignored
[
https://issues.apache.org/jira/browse/ARIES-1474?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christian Schneider reassigned ARIES-1474:
--
Assignee: Christian Schneider
> blueprint-maven-plugin: Inherited init/destroy methods are ignored
> --
>
> Key: ARIES-1474
> URL: https://issues.apache.org/jira/browse/ARIES-1474
> Project: Aries
> Issue Type: Bug
> Components: Blueprint
>Affects Versions: blueprint-maven-plugin-1.3.0
>Reporter: Sam Wright
>Assignee: Christian Schneider
> Fix For: blueprint-maven-plugin-1.4.0
>
>
> Current behaviour:
> {code}
> public class A {
> @PostConstruct
> public void init() {}
> @PreDestroy
> public void destroy() {}
> }
> public class B extends A {}
> public class C extends B {
> @Override
> public void init() {}
> @PostConstruct
> public void secondInit()
> }
> {code}
> Three problems:
> * The A.destroy() method is ignored
> * The C.init() method overrides A.init() without the @PostConstruct
> annotation, but is still taken to be the init method. This means the subclass
> can't disable a superclass' init method.
> * The C.secondInit() method is silently ignored because another init method
> is found first.
> Patch incoming...
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (ARIES-1468) Aries Transaction Blueprint bundle fails to start sometimes
[ https://issues.apache.org/jira/browse/ARIES-1468?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15055742#comment-15055742 ] Christian Schneider commented on ARIES-1468: Many thanks Guillaume. I hope this fixes the issue. If yes then we should also do a blueprint core release I think. > Aries Transaction Blueprint bundle fails to start sometimes > --- > > Key: ARIES-1468 > URL: https://issues.apache.org/jira/browse/ARIES-1468 > Project: Aries > Issue Type: Bug > Components: JMX, Transaction >Affects Versions: transaction-manager-1.3.0, jmx-1.1.5, > transaction-blueprint-2.0.0 > Environment: Windows 7 version 6.1 x64 > Java 1.7.0_80 x64 >Reporter: Viktor Kozlov >Assignee: Christian Schneider >Priority: Blocker > Fix For: jmx-1.1.6 > > > I have found some unstable behavior when starting Karaf 4.0.3. > Apache Aries Transaction Blueprint 2.0.0 bundle start success is random. > I have to restart Karaf several (about 3 to 10) times to get the error. > It looks like it is some sort of a bundle race or something. > The list of features to be installed: > feature:install -v eventadmin; > feature:install -v http-whiteboard; > feature:install -v jdbc; > feature:install -v pax-jdbc-pool-dbcp2; > feature:install -v eclipselink/2.6.0; > feature:install -v jpa/2.2.0; > Exception during Karaf start: > karaf@root()> ERROR: Bundle org.apache.aries.blueprint.core [13] > EventDispatcher: Error during dispatch. (java.lang.NullPointerException) > java.lang.NullPointerException > at > org.apache.aries.blueprint.namespace.NamespaceHandlerRegistryImpl.addingService(NamespaceHandlerRegistryImpl.java:126) > at > org.osgi.util.tracker.ServiceTracker$Tracked.customizerAdding(ServiceTracker.java:941) > at > org.osgi.util.tracker.ServiceTracker$Tracked.customizerAdding(ServiceTracker.java:870) > at > org.osgi.util.tracker.AbstractTracked.trackAdding(AbstractTracked.java:256) > at > org.osgi.util.tracker.AbstractTracked.track(AbstractTracked.java:229) > at > org.osgi.util.tracker.ServiceTracker$Tracked.serviceChanged(ServiceTracker.java:901) > at > org.apache.felix.framework.util.EventDispatcher.invokeServiceListenerCallback(EventDispatcher.java:991) > at > org.apache.felix.framework.util.EventDispatcher.fireEventImmediately(EventDispatcher.java:839) > at > org.apache.felix.framework.util.EventDispatcher.fireServiceEvent(EventDispatcher.java:546) > at org.apache.felix.framework.Felix.fireServiceEvent(Felix.java:4557) > at org.apache.felix.framework.Felix.registerService(Felix.java:3549) > at > org.apache.felix.framework.BundleContextImpl.registerService(BundleContextImpl.java:348) > at > org.apache.aries.blueprint.container.BlueprintContainerImpl.registerService(BlueprintContainerImpl.java:459) > at > org.apache.aries.blueprint.container.ServiceRecipe.register(ServiceRecipe.java:193) > at > org.apache.aries.blueprint.container.BlueprintContainerImpl.registerServices(BlueprintContainerImpl.java:710) > at > org.apache.aries.blueprint.container.BlueprintContainerImpl.doRun(BlueprintContainerImpl.java:385) > at > org.apache.aries.blueprint.container.BlueprintContainerImpl.run(BlueprintContainerImpl.java:270) > at > java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) > at java.util.concurrent.FutureTask.run(FutureTask.java:262) > at > org.apache.aries.blueprint.container.ExecutorServiceWrapper.run(ExecutorServiceWrapper.java:106) > at > org.apache.aries.blueprint.utils.threading.impl.DiscardableRunnable.run(DiscardableRunnable.java:48) > at > java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) > at java.util.concurrent.FutureTask.run(FutureTask.java:262) > at > java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:178) > at > java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:292) > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) > at java.lang.Thread.run(Thread.java:745) > Cut from bundle:list command result: > 108 | Active | 80 | 1.2 | javax.interceptor API > 109
[jira] [Updated] (ARIES-1456) Spring support
[ https://issues.apache.org/jira/browse/ARIES-1456?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schneider updated ARIES-1456: --- Fix Version/s: blueprint-parser-1.4.0 > Spring support > -- > > Key: ARIES-1456 > URL: https://issues.apache.org/jira/browse/ARIES-1456 > Project: Aries > Issue Type: New Feature > Components: Blueprint >Reporter: Guillaume Nodet >Assignee: Guillaume Nodet > Fix For: blueprint-parser-1.4.0 > > > Support for spring namespaces would be a great feature and would allow users > to completely get rid of spring-dm easily. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (ARIES-1456) Spring support
[ https://issues.apache.org/jira/browse/ARIES-1456?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schneider updated ARIES-1456: --- Affects Version/s: blueprint-parser-1.3.2 > Spring support > -- > > Key: ARIES-1456 > URL: https://issues.apache.org/jira/browse/ARIES-1456 > Project: Aries > Issue Type: New Feature > Components: Blueprint >Affects Versions: blueprint-parser-1.3.2 >Reporter: Guillaume Nodet >Assignee: Guillaume Nodet > Fix For: blueprint-parser-1.4.0, blueprint-spring-0.1.0 > > > Support for spring namespaces would be a great feature and would allow users > to completely get rid of spring-dm easily. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (ARIES-1456) Spring support
[ https://issues.apache.org/jira/browse/ARIES-1456?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schneider updated ARIES-1456: --- Fix Version/s: blueprint-spring-0.1.0 > Spring support > -- > > Key: ARIES-1456 > URL: https://issues.apache.org/jira/browse/ARIES-1456 > Project: Aries > Issue Type: New Feature > Components: Blueprint >Affects Versions: blueprint-parser-1.3.2 >Reporter: Guillaume Nodet >Assignee: Guillaume Nodet > Fix For: blueprint-parser-1.4.0, blueprint-spring-0.1.0 > > > Support for spring namespaces would be a great feature and would allow users > to completely get rid of spring-dm easily. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (ARIES-1479) Add service requirements and capabilities
Christian Schneider created ARIES-1479: -- Summary: Add service requirements and capabilities Key: ARIES-1479 URL: https://issues.apache.org/jira/browse/ARIES-1479 Project: Aries Issue Type: Improvement Components: JPA Affects Versions: jpa-2.3.0 Reporter: Christian Schneider Assignee: Christian Schneider -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (ARIES-1479) Add service requirements and capabilities
[ https://issues.apache.org/jira/browse/ARIES-1479?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schneider updated ARIES-1479: --- Fix Version/s: jpa-2.4.0 > Add service requirements and capabilities > - > > Key: ARIES-1479 > URL: https://issues.apache.org/jira/browse/ARIES-1479 > Project: Aries > Issue Type: Improvement > Components: JPA >Affects Versions: jpa-2.3.0 > Reporter: Christian Schneider >Assignee: Christian Schneider > Fix For: jpa-2.4.0 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (ARIES-1468) Aries Transaction Blueprint bundle fails to start sometimes
[ https://issues.apache.org/jira/browse/ARIES-1468?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schneider resolved ARIES-1468. Resolution: Fixed > Aries Transaction Blueprint bundle fails to start sometimes > --- > > Key: ARIES-1468 > URL: https://issues.apache.org/jira/browse/ARIES-1468 > Project: Aries > Issue Type: Bug > Components: JMX, Transaction >Affects Versions: transaction-manager-1.3.0, jmx-1.1.5, > transaction-blueprint-2.0.0 > Environment: Windows 7 version 6.1 x64 > Java 1.7.0_80 x64 >Reporter: Viktor Kozlov >Assignee: Christian Schneider >Priority: Blocker > Fix For: jmx-1.1.6 > > > I have found some unstable behavior when starting Karaf 4.0.3. > Apache Aries Transaction Blueprint 2.0.0 bundle start success is random. > I have to restart Karaf several (about 3 to 10) times to get the error. > It looks like it is some sort of a bundle race or something. > The list of features to be installed: > feature:install -v eventadmin; > feature:install -v http-whiteboard; > feature:install -v jdbc; > feature:install -v pax-jdbc-pool-dbcp2; > feature:install -v eclipselink/2.6.0; > feature:install -v jpa/2.2.0; > Exception during Karaf start: > karaf@root()> ERROR: Bundle org.apache.aries.blueprint.core [13] > EventDispatcher: Error during dispatch. (java.lang.NullPointerException) > java.lang.NullPointerException > at > org.apache.aries.blueprint.namespace.NamespaceHandlerRegistryImpl.addingService(NamespaceHandlerRegistryImpl.java:126) > at > org.osgi.util.tracker.ServiceTracker$Tracked.customizerAdding(ServiceTracker.java:941) > at > org.osgi.util.tracker.ServiceTracker$Tracked.customizerAdding(ServiceTracker.java:870) > at > org.osgi.util.tracker.AbstractTracked.trackAdding(AbstractTracked.java:256) > at > org.osgi.util.tracker.AbstractTracked.track(AbstractTracked.java:229) > at > org.osgi.util.tracker.ServiceTracker$Tracked.serviceChanged(ServiceTracker.java:901) > at > org.apache.felix.framework.util.EventDispatcher.invokeServiceListenerCallback(EventDispatcher.java:991) > at > org.apache.felix.framework.util.EventDispatcher.fireEventImmediately(EventDispatcher.java:839) > at > org.apache.felix.framework.util.EventDispatcher.fireServiceEvent(EventDispatcher.java:546) > at org.apache.felix.framework.Felix.fireServiceEvent(Felix.java:4557) > at org.apache.felix.framework.Felix.registerService(Felix.java:3549) > at > org.apache.felix.framework.BundleContextImpl.registerService(BundleContextImpl.java:348) > at > org.apache.aries.blueprint.container.BlueprintContainerImpl.registerService(BlueprintContainerImpl.java:459) > at > org.apache.aries.blueprint.container.ServiceRecipe.register(ServiceRecipe.java:193) > at > org.apache.aries.blueprint.container.BlueprintContainerImpl.registerServices(BlueprintContainerImpl.java:710) > at > org.apache.aries.blueprint.container.BlueprintContainerImpl.doRun(BlueprintContainerImpl.java:385) > at > org.apache.aries.blueprint.container.BlueprintContainerImpl.run(BlueprintContainerImpl.java:270) > at > java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) > at java.util.concurrent.FutureTask.run(FutureTask.java:262) > at > org.apache.aries.blueprint.container.ExecutorServiceWrapper.run(ExecutorServiceWrapper.java:106) > at > org.apache.aries.blueprint.utils.threading.impl.DiscardableRunnable.run(DiscardableRunnable.java:48) > at > java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) > at java.util.concurrent.FutureTask.run(FutureTask.java:262) > at > java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:178) > at > java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:292) > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) > at java.lang.Thread.run(Thread.java:745) > Cut from bundle:list command result: > 108 | Active | 80 | 1.2 | javax.interceptor API > 109 | Active | 80 | 1.2 | javax.transaction API > 110 | Active | 80 | 1.1.1 | Apache Aries Transaction >
[jira] [Created] (ARIES-1484) Only write blueprint context if any beans are discovered
Christian Schneider created ARIES-1484: -- Summary: Only write blueprint context if any beans are discovered Key: ARIES-1484 URL: https://issues.apache.org/jira/browse/ARIES-1484 Project: Aries Issue Type: Improvement Components: Blueprint Affects Versions: blueprint-maven-plugin-1.3.0 Reporter: Christian Schneider Assignee: Christian Schneider Fix For: blueprint-maven-plugin-1.4.0 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (ARIES-1484) Only write blueprint context if any beans are discovered
[ https://issues.apache.org/jira/browse/ARIES-1484?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schneider resolved ARIES-1484. Resolution: Fixed > Only write blueprint context if any beans are discovered > > > Key: ARIES-1484 > URL: https://issues.apache.org/jira/browse/ARIES-1484 > Project: Aries > Issue Type: Improvement > Components: Blueprint >Affects Versions: blueprint-maven-plugin-1.3.0 > Reporter: Christian Schneider >Assignee: Christian Schneider > Fix For: blueprint-maven-plugin-1.4.0 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (ARIES-1474) blueprint-maven-plugin: Inherited init/destroy methods are ignored
[
https://issues.apache.org/jira/browse/ARIES-1474?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15093750#comment-15093750
]
Christian Schneider commented on ARIES-1474:
There is a problem with the pull request. The two new classes have headers like:
// EGS-CC
// (C) Copyright European Space Agency, 2015
You need to give them the default apache header.
I am pretty sure this was unintended but in accepting the PR I would pollute
the apache code with non apache license.
> blueprint-maven-plugin: Inherited init/destroy methods are ignored
> --
>
> Key: ARIES-1474
> URL: https://issues.apache.org/jira/browse/ARIES-1474
> Project: Aries
> Issue Type: Bug
> Components: Blueprint
>Affects Versions: blueprint-maven-plugin-1.3.0
>Reporter: Sam Wright
>Assignee: Christian Schneider
> Fix For: blueprint-maven-plugin-1.4.0
>
>
> Current behaviour:
> {code}
> public class A {
> @PostConstruct
> public void init() {}
> @PreDestroy
> public void destroy() {}
> }
> public class B extends A {}
> public class C extends B {
> @Override
> public void init() {}
> @PostConstruct
> public void secondInit()
> }
> {code}
> Three problems:
> * The A.destroy() method is ignored
> * The C.init() method overrides A.init() without the @PostConstruct
> annotation, but is still taken to be the init method. This means the subclass
> can't disable a superclass' init method.
> * The C.secondInit() method is silently ignored because another init method
> is found first.
> Patch incoming...
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (ARIES-1474) blueprint-maven-plugin: Inherited init/destroy methods are ignored
[
https://issues.apache.org/jira/browse/ARIES-1474?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15093832#comment-15093832
]
Christian Schneider commented on ARIES-1474:
As these are very small files I would be ok if you state here that the files
were intended to have the apache license.
> blueprint-maven-plugin: Inherited init/destroy methods are ignored
> --
>
> Key: ARIES-1474
> URL: https://issues.apache.org/jira/browse/ARIES-1474
> Project: Aries
> Issue Type: Bug
> Components: Blueprint
>Affects Versions: blueprint-maven-plugin-1.3.0
>Reporter: Sam Wright
>Assignee: Christian Schneider
> Fix For: blueprint-maven-plugin-1.4.0
>
>
> Current behaviour:
> {code}
> public class A {
> @PostConstruct
> public void init() {}
> @PreDestroy
> public void destroy() {}
> }
> public class B extends A {}
> public class C extends B {
> @Override
> public void init() {}
> @PostConstruct
> public void secondInit()
> }
> {code}
> Three problems:
> * The A.destroy() method is ignored
> * The C.init() method overrides A.init() without the @PostConstruct
> annotation, but is still taken to be the init method. This means the subclass
> can't disable a superclass' init method.
> * The C.secondInit() method is silently ignored because another init method
> is found first.
> Patch incoming...
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
