[jira] [Closed] (ARIES-1891) Memory Leak in aries-jpa-support
[ https://issues.apache.org/jira/browse/ARIES-1891?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Estermann closed ARIES-1891. --- Resolution: Fixed The memory leak is fixed in https://github.com/apache/aries-jpa/commit/8f46ae5c58e90832ab8886ab6f5d7c7d9f7fada2 > Memory Leak in aries-jpa-support > > > Key: ARIES-1891 > URL: https://issues.apache.org/jira/browse/ARIES-1891 > Project: Aries > Issue Type: Bug > Components: JPA >Affects Versions: jpa-2.7.1 >Reporter: Daniel Estermann >Priority: Critical > Fix For: jpa-2.7.2 > > > The fix for ARIES-1783 has a memory leak. The method > org.apache.aries.jpa.supplier.EmSupplier.get() is called every time when a > method on EntityManager is called. And every time a ServiceReference to a > TransactionManager gets created. But it doesn't get deleted. So we have as > many ServiceReferences in the memory as calls on EntityManager. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (ARIES-1891) Memory Leak in aries-jpa-support
Daniel Estermann created ARIES-1891: --- Summary: Memory Leak in aries-jpa-support Key: ARIES-1891 URL: https://issues.apache.org/jira/browse/ARIES-1891 Project: Aries Issue Type: Bug Components: JPA Affects Versions: jpa-2.7.1 Reporter: Daniel Estermann Fix For: jpa-2.7.2 The fix for ARIES-1783 has a memory leak. The method org.apache.aries.jpa.supplier.EmSupplier.get() is called every time when a method on EntityManager is called. And every time a ServiceReference to a TransactionManager gets created. But it doesn't get deleted. So we have as many ServiceReferences in the memory as calls on EntityManager. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (ARIES-1886) Globally configurable number of extender threads and grace period timeout
Daniel Estermann created ARIES-1886:
---
Summary: Globally configurable number of extender threads and
grace period timeout
Key: ARIES-1886
URL: https://issues.apache.org/jira/browse/ARIES-1886
Project: Aries
Issue Type: Wish
Components: Blueprint
Affects Versions: blueprint-core-1.9.0
Reporter: Daniel Estermann
At Seeburger AG we migrated from JBoss to Karaf. We use Aries modules for
transaction capable beans. Since the migration, the number of blueprint bundles
increased and we started to get errors of this kind:
{code}
org.apache.aries.blueprint.container.BlueprintContainerImpl JB2688
Blueprint Extender: 1 B6AIO1@b6aio1bd4ef ERROR
Unable to start blueprint container for bundle
com.seeburger.portal.backend/2.55.0 due to unresolved dependencies
[(objectClass=javax.transaction.TransactionSynchronizationRegistry)]
@LGW800 2018-07-04T12:01:36.637+0200
{code}
So we tried to increase the number of extender threads and grace period timeout
in our blueprint fork to fix it. We introduced this in our master branch in
July 2018 and it increased the stability of our software. This is why we want
to propose this change also to be done in aries, which can be reviewed in
[PR91|https://github.com/apache/aries/pull/91]
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (ARIES-1800) rollbackOn element of Transactional annotation ignored when set on class level
[ https://issues.apache.org/jira/browse/ARIES-1800?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16467144#comment-16467144 ] Daniel Estermann commented on ARIES-1800: - I agree [~ch...@die-schneider.net] and will implement it on my branch https://github.com/Smasherr/aries/tree/ARIES-1800 > rollbackOn element of Transactional annotation ignored when set on class level > -- > > Key: ARIES-1800 > URL: https://issues.apache.org/jira/browse/ARIES-1800 > Project: Aries > Issue Type: Bug > Components: Transaction >Affects Versions: transaction-blueprint-2.2.0 >Reporter: Daniel Estermann >Priority: Major > > Since ARIES-1690 the methods throwing a checked exception cause a rollback if > the related exception is marked for a rollback using rollbackOn element of > Transactional annotation set on a method. However this doesn't work for > Transactional annotations on the class level. > We also need to clarify how we should handle a exceptions set on both levels > class and method. There are at least two options: > * The resulting set of exceptions marked for rollback is an aggregation from > both class level and method level annotation. > * Exception set defined on the method level overrides exceptions of the class > leve. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (ARIES-1800) rollbackOn element of Transactional annotation ignored when set on class level
[ https://issues.apache.org/jira/browse/ARIES-1800?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Estermann updated ARIES-1800: Description: Since ARIES-1690 the methods throwing a checked exception cause a rollback if the related exception is marked for a rollback using rollbackOn element of Transactional annotation set on a method. However this doesn't work for Transactional annotations on the class level. We also need to clarify how we should handle a exceptions set on both levels class and method. There are at least two options: * The resulting set of exceptions marked for rollback is an aggregation from both class level and method level annotation. * Exception set defined on the method level overrides exceptions of the class leve. was: Since ARIES-1690 the methods throwing a checked exception cause a rollback if the related exception is marked for a rollback using rollbackOn element of Transactional annotation set on a method. However this doesn't work for Transactional annotations on the class level. I would expect a set of exceptions marked for rollback to get aggregated from both class level and method level annotation. > rollbackOn element of Transactional annotation ignored when set on class level > -- > > Key: ARIES-1800 > URL: https://issues.apache.org/jira/browse/ARIES-1800 > Project: Aries > Issue Type: Bug > Components: Transaction >Affects Versions: transaction-blueprint-2.2.0 >Reporter: Daniel Estermann >Priority: Major > > Since ARIES-1690 the methods throwing a checked exception cause a rollback if > the related exception is marked for a rollback using rollbackOn element of > Transactional annotation set on a method. However this doesn't work for > Transactional annotations on the class level. > We also need to clarify how we should handle a exceptions set on both levels > class and method. There are at least two options: > * The resulting set of exceptions marked for rollback is an aggregation from > both class level and method level annotation. > * Exception set defined on the method level overrides exceptions of the class > leve. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (ARIES-1800) rollbackOn element of Transactional annotation ignored when set on class level
Daniel Estermann created ARIES-1800: --- Summary: rollbackOn element of Transactional annotation ignored when set on class level Key: ARIES-1800 URL: https://issues.apache.org/jira/browse/ARIES-1800 Project: Aries Issue Type: Bug Components: Transaction Affects Versions: transaction-blueprint-2.2.0 Reporter: Daniel Estermann Since ARIES-1690 the methods throwing a checked exception cause a rollback if the related exception is marked for a rollback using rollbackOn element of Transactional annotation set on a method. However this doesn't work for Transactional annotations on the class level. I would expect a set of exceptions marked for rollback to get aggregated from both class level and method level annotation. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ARIES-1792) blueprint-maven-plugin slows down compilation
[ https://issues.apache.org/jira/browse/ARIES-1792?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16439434#comment-16439434 ] Daniel Estermann commented on ARIES-1792: - I can confirm - xbean-finder-shaded:4.7 doesn't improve the build time > blueprint-maven-plugin slows down compilation > - > > Key: ARIES-1792 > URL: https://issues.apache.org/jira/browse/ARIES-1792 > Project: Aries > Issue Type: Improvement >Affects Versions: blueprint-maven-plugin-1.9.0 >Reporter: Xavier Roussel >Priority: Major > > We have a maven project with 20+ modules all using BMP to generate blueprint > file. > During compilation, BMP is executed on each module and represents more than > 70% of the project's compilation time. > We specify a scanPath for each module as a parameter to BMP but it seems that > it scan the module and also all the dependencies so because the modules are > linked together, the whole project is scanned again and again for each module. > It could be useful to add an option to exclude dependencies so that BMP only > scan the current module. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (ARIES-1792) blueprint-maven-plugin slows down compilation
[ https://issues.apache.org/jira/browse/ARIES-1792?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16439178#comment-16439178 ] Daniel Estermann edited comment on ARIES-1792 at 4/16/18 11:51 AM: --- The fix didn't work for me unfortunately. Here is the log: https://paste.fedoraproject.org/paste/ALB-AoWe0lc9SB1afiaRUw Current stable version of the plugin with the same project takes the same amount of time, about 11 seconds: https://paste.fedoraproject.org/paste/Ou~7U8xGAV6oulNR7Y4smw was (Author: soundcrac...@gmail.com): The fix didn't work for me unfortunately. Here is the log: https://paste.fedoraproject.org/paste/ALB-AoWe0lc9SB1afiaRUw The master version of the plugin takes about the same amount of time: https://paste.fedoraproject.org/paste/z0mMIpXLXMWqHFfet-mVRw > blueprint-maven-plugin slows down compilation > - > > Key: ARIES-1792 > URL: https://issues.apache.org/jira/browse/ARIES-1792 > Project: Aries > Issue Type: Improvement >Affects Versions: blueprint-maven-plugin-1.9.0 >Reporter: Xavier Roussel >Priority: Major > > We have a maven project with 20+ modules all using BMP to generate blueprint > file. > During compilation, BMP is executed on each module and represents more than > 70% of the project's compilation time. > We specify a scanPath for each module as a parameter to BMP but it seems that > it scan the module and also all the dependencies so because the modules are > linked together, the whole project is scanned again and again for each module. > It could be useful to add an option to exclude dependencies so that BMP only > scan the current module. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (ARIES-1792) blueprint-maven-plugin slows down compilation
[ https://issues.apache.org/jira/browse/ARIES-1792?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16439178#comment-16439178 ] Daniel Estermann edited comment on ARIES-1792 at 4/16/18 9:51 AM: -- The fix didn't work for me unfortunately. Here is the log: https://paste.fedoraproject.org/paste/ALB-AoWe0lc9SB1afiaRUw The master version of the plugin takes about the same amount of time: https://paste.fedoraproject.org/paste/z0mMIpXLXMWqHFfet-mVRw was (Author: soundcrac...@gmail.com): The fix didn't work for me unfortunately. Here is the log: https://paste.fedoraproject.org/paste/iBmXy-C65Nj5I2-ehhcfMA The master version of the plugin takes about the same amount of time. > blueprint-maven-plugin slows down compilation > - > > Key: ARIES-1792 > URL: https://issues.apache.org/jira/browse/ARIES-1792 > Project: Aries > Issue Type: Improvement >Affects Versions: blueprint-maven-plugin-1.9.0 >Reporter: Xavier Roussel >Priority: Major > > We have a maven project with 20+ modules all using BMP to generate blueprint > file. > During compilation, BMP is executed on each module and represents more than > 70% of the project's compilation time. > We specify a scanPath for each module as a parameter to BMP but it seems that > it scan the module and also all the dependencies so because the modules are > linked together, the whole project is scanned again and again for each module. > It could be useful to add an option to exclude dependencies so that BMP only > scan the current module. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (ARIES-1792) blueprint-maven-plugin slows down compilation
[ https://issues.apache.org/jira/browse/ARIES-1792?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16439178#comment-16439178 ] Daniel Estermann edited comment on ARIES-1792 at 4/16/18 9:48 AM: -- The fix didn't work for me unfortunately. Here is the log: https://paste.fedoraproject.org/paste/iBmXy-C65Nj5I2-ehhcfMA The master version of the plugin takes about the same amount of time. was (Author: soundcrac...@gmail.com): The fix didn't work for me unfortunately. Here is the log: https://paste.fedoraproject.org/paste/iBmXy-C65Nj5I2-ehhcfMA > blueprint-maven-plugin slows down compilation > - > > Key: ARIES-1792 > URL: https://issues.apache.org/jira/browse/ARIES-1792 > Project: Aries > Issue Type: Improvement >Affects Versions: blueprint-maven-plugin-1.9.0 >Reporter: Xavier Roussel >Priority: Major > > We have a maven project with 20+ modules all using BMP to generate blueprint > file. > During compilation, BMP is executed on each module and represents more than > 70% of the project's compilation time. > We specify a scanPath for each module as a parameter to BMP but it seems that > it scan the module and also all the dependencies so because the modules are > linked together, the whole project is scanned again and again for each module. > It could be useful to add an option to exclude dependencies so that BMP only > scan the current module. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ARIES-1792) blueprint-maven-plugin slows down compilation
[ https://issues.apache.org/jira/browse/ARIES-1792?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16439178#comment-16439178 ] Daniel Estermann commented on ARIES-1792: - The fix didn't work for me unfortunately. Here is the log: https://paste.fedoraproject.org/paste/iBmXy-C65Nj5I2-ehhcfMA > blueprint-maven-plugin slows down compilation > - > > Key: ARIES-1792 > URL: https://issues.apache.org/jira/browse/ARIES-1792 > Project: Aries > Issue Type: Improvement >Affects Versions: blueprint-maven-plugin-1.9.0 >Reporter: Xavier Roussel >Priority: Major > > We have a maven project with 20+ modules all using BMP to generate blueprint > file. > During compilation, BMP is executed on each module and represents more than > 70% of the project's compilation time. > We specify a scanPath for each module as a parameter to BMP but it seems that > it scan the module and also all the dependencies so because the modules are > linked together, the whole project is scanned again and again for each module. > It could be useful to add an option to exclude dependencies so that BMP only > scan the current module. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ARIES-1792) blueprint-maven-plugin slows down compilation
[ https://issues.apache.org/jira/browse/ARIES-1792?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16437605#comment-16437605 ] Daniel Estermann commented on ARIES-1792: - [~alien11689] I will test your optimization on monday, when I'm back in my office. This looks like a kind of an optimization, which I asked for in ARIES-1772 > blueprint-maven-plugin slows down compilation > - > > Key: ARIES-1792 > URL: https://issues.apache.org/jira/browse/ARIES-1792 > Project: Aries > Issue Type: Improvement >Affects Versions: blueprint-maven-plugin-1.9.0 >Reporter: Xavier Roussel >Priority: Major > > We have a maven project with 20+ modules all using BMP to generate blueprint > file. > During compilation, BMP is executed on each module and represents more than > 70% of the project's compilation time. > We specify a scanPath for each module as a parameter to BMP but it seems that > it scan the module and also all the dependencies so because the modules are > linked together, the whole project is scanned again and again for each module. > It could be useful to add an option to exclude dependencies so that BMP only > scan the current module. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ARIES-1792) blueprint-maven-plugin slows down compilation
[ https://issues.apache.org/jira/browse/ARIES-1792?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16437311#comment-16437311 ] Daniel Estermann commented on ARIES-1792: - Please see the linked issue opened by me. In my projects this plugin not only consumes the compile time (I even didn't mention it), it also makes my builds fail. > blueprint-maven-plugin slows down compilation > - > > Key: ARIES-1792 > URL: https://issues.apache.org/jira/browse/ARIES-1792 > Project: Aries > Issue Type: Improvement >Affects Versions: blueprint-maven-plugin-1.9.0 >Reporter: Xavier Roussel >Priority: Major > > We have a maven project with 20+ modules all using BMP to generate blueprint > file. > During compilation, BMP is executed on each module and represents more than > 70% of the project's compilation time. > We specify a scanPath for each module as a parameter to BMP but it seems that > it scan the module and also all the dependencies so because the modules are > linked together, the whole project is scanned again and again for each module. > It could be useful to add an option to exclude dependencies so that BMP only > scan the current module. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ARIES-1772) Add an option to blueprint-maven-plugin to exclude dependencies.
[
https://issues.apache.org/jira/browse/ARIES-1772?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16370244#comment-16370244
]
Daniel Estermann commented on ARIES-1772:
-
Hi Dominik, thank you for your work so far. I found out that the problem occurs
also with the transitive dependencies of the provided dependencies. The
situation I have is following:
{code:xml}
A
B
provided
{code}
{code:xml}
B
org.glassfish.jersey.media
jersey-media-json-jackson
${version.jersey}
{code}
Trying to build project A results in:
{code:java}
[ERROR] Failed to execute goal
org.apache.aries.blueprint:blueprint-maven-plugin:1.9.0:blueprint-generate
(default) on project portal-backend: Execution default of goal
org.apache.aries.blueprint:blueprint-maven-plugin:1.9.0:blueprint-generate
failed: A required class was missing while executing
org.apache.aries.blueprint:blueprint-maven-plugin:1.9.0:blueprint-generate:
com/fasterxml/jackson/jaxrs/json/JacksonJaxbJsonProvider
[ERROR] -
[ERROR] realm = plugin>org.apache.aries.blueprint:blueprint-maven-plugin:1.9.0
[ERROR] strategy = org.codehaus.plexus.classworlds.strategy.SelfFirstStrategy
[ERROR] urls[0] =
file:/d:/.m2/repository/org/apache/aries/blueprint/blueprint-maven-plugin/1.9.0/blueprint-maven-plugin-1.9.0.jar
...skipped...
...jersey-media-json-jackson is missing here...
[ERROR] urls[44] ...
[ERROR] Number of foreign imports: 1
[ERROR] import: Entry[import from realm
ClassRealm[project>com.seeburger.portal:portal-backend:2.50.0-SNAPSHOT, parent:
ClassRealm[maven.api, parent: null]]]
[ERROR]
[ERROR] -:
com.fasterxml.jackson.jaxrs.json.JacksonJaxbJsonProvider
{code}
I looked at the code of the plugin and noticed two things, which are related to
the error.
# The filtering of the scanned classes using the scanPath parameter happens
+after+ the scanning. FilteredClassFinder.findClasses(...) find the annotated
classes first and then applies the filter by calling filterByBasePackages(..).
That's why I cannot really constraint the scanning via that parameter.
{code:java}
org.apache.aries.blueprint.plugin.FilteredClassFinder:36
private static Set findClasses(ClassFinder finder, Collection
packageNames, Class[] annotations) {
Set rawClasses = new HashSet();
for (Class annotation : annotations) {
rawClasses.addAll(finder.findAnnotatedClasses(annotation));
}
return filterByBasePackages(rawClasses, packageNames);
}{code}
# The ClassFinder gets initialized using a URLClassLoader, which contains a
set of JARs including the transitive dependencies of the provided dependencies.
{code:java}
org.apache.aries.blueprint.plugin.GenerateMojo:175
private ClassFinder createProjectScopeFinder() {
for (Object artifactO : project.getArtifacts()) {
//...
urls.add(file.toURI().toURL());
}
ClassLoader loader = new URLClassLoader(urls.toArray(new URL[urls.size()]),
getClass().getClassLoader());
return new ClassFinder(loader, urls);
}{code}
Project.getArtifacts() returns 120 objects while the amount of jar on the build
classpath is 45. Especially jersey-media-json-jackson.jar containing
JacksonJaxbJsonProvider is one of the JARs returned by getArtifacts(). No idea
why that happens, maybe bug in maven? I use Maven 3.2.1 for CI and 3.5.2
locally, if that matters.
!test.png!
> Add an option to blueprint-maven-plugin to exclude dependencies.
>
>
> Key: ARIES-1772
> URL: https://issues.apache.org/jira/browse/ARIES-1772
> Project: Aries
> Issue Type: New Feature
> Components: Blueprint
>Affects Versions: blueprint-maven-plugin-1.9.0
>Reporter: Daniel Estermann
>Assignee: Dominik Przybysz
>Priority: Major
> Attachments: test.png, test.png
>
>
> Currently the list of scanned classes by blueprint-maven-plugin can be
> restricted using scanPath parameter, so the list can also contain the classes
> of the project dependencies. With my projects I experience two kind of issues
> with it:
> * If the the scan path is chosen too widely it may lead to a build failure.
> For example: Assume project A has a dependency to project B an both have the
> same base package, which is chosen as the scan path. Project B has a
> blueprint bean, which implements an interface from some +provided+ dependency
> of it. The build of project A will fail then, because it will try to scan a
> blueprint bean of project B but it will miss its provided dependency. An
> example error message:
>
> {code:java}
> Failed to execute goal
>
[jira] [Updated] (ARIES-1772) Add an option to blueprint-maven-plugin to exclude dependencies.
[
https://issues.apache.org/jira/browse/ARIES-1772?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Estermann updated ARIES-1772:
Attachment: test.png
> Add an option to blueprint-maven-plugin to exclude dependencies.
>
>
> Key: ARIES-1772
> URL: https://issues.apache.org/jira/browse/ARIES-1772
> Project: Aries
> Issue Type: New Feature
> Components: Blueprint
>Affects Versions: blueprint-maven-plugin-1.9.0
>Reporter: Daniel Estermann
>Assignee: Dominik Przybysz
>Priority: Major
> Attachments: test.png, test.png
>
>
> Currently the list of scanned classes by blueprint-maven-plugin can be
> restricted using scanPath parameter, so the list can also contain the classes
> of the project dependencies. With my projects I experience two kind of issues
> with it:
> * If the the scan path is chosen too widely it may lead to a build failure.
> For example: Assume project A has a dependency to project B an both have the
> same base package, which is chosen as the scan path. Project B has a
> blueprint bean, which implements an interface from some +provided+ dependency
> of it. The build of project A will fail then, because it will try to scan a
> blueprint bean of project B but it will miss its provided dependency. An
> example error message:
>
> {code:java}
> Failed to execute goal
> org.apache.aries.blueprint:blueprint-maven-plugin:1.9.0:blueprint-generate
> (default) on project email-template-editor-core: Execution default of goal
> org.apache.aries.blueprint:blueprint-maven-plugin:1.9.0:blueprint-generate
> failed: A required class was missing while executing
> org.apache.aries.blueprint:blueprint-maven-plugin:1.9.0:blueprint-generate:
> com/mycorporation/scheduler/api/ScheduledService{code}
>
> * If a bean of project B appears in the autowire.xml of project A, but the
> package of that bean is not imported in the manifest of project A, a
> ClassNotFoundException will be thrown during runtime:
>
> {code:java}
> java.lang.ClassNotFoundException:
> com.mycorporation.project-a.commons.notification.IncomingNotificationService
> from [Module
> "deployment.com.mycorporation.project-b.commons.core:0.0.1.SNAPSHOT" from
> Service Module Loader]
> {code}
>
> I suggest to add an option, to exclude dependencies from the list of scanned
> classes, like [maven-bundle-plugin's
> excludeDependencies|http://felix.apache.org/components/bundle-plugin/bundle-mojo.html#excludeDependencies]
> for example, and give this option per default such value as to exclude all
> dependencies.
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (ARIES-1772) Add an option to blueprint-maven-plugin to exclude dependencies.
[
https://issues.apache.org/jira/browse/ARIES-1772?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Estermann updated ARIES-1772:
Attachment: test.png
> Add an option to blueprint-maven-plugin to exclude dependencies.
>
>
> Key: ARIES-1772
> URL: https://issues.apache.org/jira/browse/ARIES-1772
> Project: Aries
> Issue Type: New Feature
> Components: Blueprint
>Affects Versions: blueprint-maven-plugin-1.9.0
>Reporter: Daniel Estermann
>Assignee: Dominik Przybysz
>Priority: Major
> Attachments: test.png
>
>
> Currently the list of scanned classes by blueprint-maven-plugin can be
> restricted using scanPath parameter, so the list can also contain the classes
> of the project dependencies. With my projects I experience two kind of issues
> with it:
> * If the the scan path is chosen too widely it may lead to a build failure.
> For example: Assume project A has a dependency to project B an both have the
> same base package, which is chosen as the scan path. Project B has a
> blueprint bean, which implements an interface from some +provided+ dependency
> of it. The build of project A will fail then, because it will try to scan a
> blueprint bean of project B but it will miss its provided dependency. An
> example error message:
>
> {code:java}
> Failed to execute goal
> org.apache.aries.blueprint:blueprint-maven-plugin:1.9.0:blueprint-generate
> (default) on project email-template-editor-core: Execution default of goal
> org.apache.aries.blueprint:blueprint-maven-plugin:1.9.0:blueprint-generate
> failed: A required class was missing while executing
> org.apache.aries.blueprint:blueprint-maven-plugin:1.9.0:blueprint-generate:
> com/mycorporation/scheduler/api/ScheduledService{code}
>
> * If a bean of project B appears in the autowire.xml of project A, but the
> package of that bean is not imported in the manifest of project A, a
> ClassNotFoundException will be thrown during runtime:
>
> {code:java}
> java.lang.ClassNotFoundException:
> com.mycorporation.project-a.commons.notification.IncomingNotificationService
> from [Module
> "deployment.com.mycorporation.project-b.commons.core:0.0.1.SNAPSHOT" from
> Service Module Loader]
> {code}
>
> I suggest to add an option, to exclude dependencies from the list of scanned
> classes, like [maven-bundle-plugin's
> excludeDependencies|http://felix.apache.org/components/bundle-plugin/bundle-mojo.html#excludeDependencies]
> for example, and give this option per default such value as to exclude all
> dependencies.
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (ARIES-1783) TransactionRequiredException when non-transactional method precedes a transactional one in the same service.
Daniel Estermann created ARIES-1783: --- Summary: TransactionRequiredException when non-transactional method precedes a transactional one in the same service. Key: ARIES-1783 URL: https://issues.apache.org/jira/browse/ARIES-1783 Project: Aries Issue Type: Bug Components: JPA Affects Versions: jpa-2.5.0 Reporter: Daniel Estermann Assume I have a service implementation with a method annotated with @Transactional and one of TxTypes not starting a transaction: * NEVER * NOT_SUPPORTED * SUPPORTS >From that non-transactional method I want to use a self-reference resolved via >BundleContext to call a transactional method in the same service, annotated >with one of those TxTypes: * REQUIRED * REQURES_NEW Since the resolved self-reference is a proxied object I expect it to be able to start a new transaction. This is not the case however and the subject exception occurs. I created a test case revealing the issue in the following pull request: https://github.com/apache/aries-jpa/pull/2 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (ARIES-1772) Add an option to blueprint-maven-plugin to exclude dependencies.
[
https://issues.apache.org/jira/browse/ARIES-1772?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Estermann updated ARIES-1772:
Description:
Currently the list of scanned classes by blueprint-maven-plugin can be
restricted using scanPath parameter, so the list can also contain the classes
of the project dependencies. With my projects I experience two kind of issues
with it:
* If the the scan path is chosen too widely it may lead to a build failure.
For example: Assume project A has a dependency to project B an both have the
same base package, which is chosen as the scan path. Project B has a blueprint
bean, which implements an interface from some +provided+ dependency of it. The
build of project A will fail then, because it will try to scan a blueprint bean
of project B but it will miss its provided dependency. An example error message:
{code:java}
Failed to execute goal
org.apache.aries.blueprint:blueprint-maven-plugin:1.9.0:blueprint-generate
(default) on project email-template-editor-core: Execution default of goal
org.apache.aries.blueprint:blueprint-maven-plugin:1.9.0:blueprint-generate
failed: A required class was missing while executing
org.apache.aries.blueprint:blueprint-maven-plugin:1.9.0:blueprint-generate:
com/mycorporation/scheduler/api/ScheduledService{code}
* If a bean of project B appears in the autowire.xml of project A, but the
package of that bean is not imported in the manifest of project A, a
ClassNotFoundException will be thrown during runtime:
{code:java}
java.lang.ClassNotFoundException:
com.mycorporation.project-a.commons.notification.IncomingNotificationService
from [Module
"deployment.com.mycorporation.project-b.commons.core:0.0.1.SNAPSHOT" from
Service Module Loader]
{code}
I suggest to add an option, to exclude dependencies from the list of scanned
classes, like [maven-bundle-plugin's
excludeDependencies|http://felix.apache.org/components/bundle-plugin/bundle-mojo.html#excludeDependencies]
for example, and give this option per default such value as to exclude all
dependencies.
was:
Currently the list of scanned classes by blueprint-maven-plugin can be
restricted using scanPath parameter, so the list can also contain the classes
of the project dependencies. With my projects I experience two kind of issues
with it:
* If the the scan path is chosen too widely it may lead to a build failure.
For example: Assume project A has a dependency to project B an both have the
same base package, which is chosen as the scan path. Project B has a blueprint
bean, which implements an interface from some +provided+ dependency of it. The
build of project A will fail then, because it will try to scan a blueprint bean
of project B but it will miss its provided dependency. An example error message:
{code:java}
Failed to execute goal
org.apache.aries.blueprint:blueprint-maven-plugin:1.9.0:blueprint-generate
(default) on project email-template-editor-core: Execution default of goal
org.apache.aries.blueprint:blueprint-maven-plugin:1.9.0:blueprint-generate
failed: A required class was missing while executing
org.apache.aries.blueprint:blueprint-maven-plugin:1.9.0:blueprint-generate:
com/mycorporation/scheduler/api/ScheduledService{code}
* If a bean of project B appears in the autowire.xml of project A, but the
package of that bean is not imported in the manifest of project A, a
ClassNotFoundException will be thrown during runtime:
{code:java}
java.lang.ClassNotFoundException:
com.mycorporation.project-a.commons.notification.IncomingNotificationService
from [Module
"deployment.com.mycorporation.project-b.commons.core:0.0.1.SNAPSHOT" from
Service Module Loader]
{code}
I suggest to add an option, to exclude dependencies from the list of scanned
classes, like [maven-bundle-plugin's
excludeDependencies|http://felix.apache.org/components/bundle-plugin/bundle-mojo.html#excludeDependencies]
for example.
> Add an option to blueprint-maven-plugin to exclude dependencies.
>
>
> Key: ARIES-1772
> URL: https://issues.apache.org/jira/browse/ARIES-1772
> Project: Aries
> Issue Type: New Feature
> Components: Blueprint
>Affects Versions: blueprint-maven-plugin-1.9.0
>Reporter: Daniel Estermann
>Assignee: Dominik Przybysz
>Priority: Major
>
> Currently the list of scanned classes by blueprint-maven-plugin can be
> restricted using scanPath parameter, so the list can also contain the classes
> of the project dependencies. With my projects I experience two kind of issues
> with it:
> * If the the scan path is chosen too widely it may lead to a build failure.
> For example: Assume project A has a dependency to project B an both have the
> same base package, which is chosen as the scan path.
[jira] [Created] (ARIES-1772) Add an option to blueprint-maven-plugin to exclude dependencies.
Daniel Estermann created ARIES-1772:
---
Summary: Add an option to blueprint-maven-plugin to exclude
dependencies.
Key: ARIES-1772
URL: https://issues.apache.org/jira/browse/ARIES-1772
Project: Aries
Issue Type: New Feature
Components: Blueprint
Affects Versions: blueprint-maven-plugin-1.9.0
Reporter: Daniel Estermann
Currently the list of scanned classes by blueprint-maven-plugin can be
restricted using scanPath parameter, so the list can also contain the classes
of the project dependencies. With my projects I experience two kind of issues
with it:
* If the the scan path is chosen too widely it may lead to a build failure.
For example: Assume project A has a dependency to project B an both have the
same base package, which is chosen as the scan path. Project B has a blueprint
bean, which implements an interface from some +provided+ dependency of it. The
build of project A will fail then, because it will try to scan a blueprint bean
of project B but it will miss its provided dependency. An example error message:
{code:java}
Failed to execute goal
org.apache.aries.blueprint:blueprint-maven-plugin:1.9.0:blueprint-generate
(default) on project email-template-editor-core: Execution default of goal
org.apache.aries.blueprint:blueprint-maven-plugin:1.9.0:blueprint-generate
failed: A required class was missing while executing
org.apache.aries.blueprint:blueprint-maven-plugin:1.9.0:blueprint-generate:
com/mycorporation/scheduler/api/ScheduledService{code}
* If a bean of project B appears in the autowire.xml of project A, but the
package of that bean is not imported in the manifest of project A, a
ClassNotFoundException will be thrown during runtime:
{code:java}
java.lang.ClassNotFoundException:
com.mycorporation.project-a.commons.notification.IncomingNotificationService
from [Module
"deployment.com.mycorporation.project-b.commons.core:0.0.1.SNAPSHOT" from
Service Module Loader]
{code}
I suggest to add an option, to exclude dependencies from the list of scanned
classes, like [maven-bundle-plugin's
excludeDependencies|http://felix.apache.org/components/bundle-plugin/bundle-mojo.html#excludeDependencies]
for example.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (ARIES-1715) Blueprint doesn't apply interceptors for the init-method.
[
https://issues.apache.org/jira/browse/ARIES-1715?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16178887#comment-16178887
]
Daniel Estermann commented on ARIES-1715:
-
Correct me if I'm wrong, but Aires should behave in the same way like Java EE
components behave. The usage of an EntityManager in a method annotated with
@PostConstruct works for example with EJBs on JBoss AS 7.1. That's why I
consider it as a bug.
> Blueprint doesn't apply interceptors for the init-method.
> -
>
> Key: ARIES-1715
> URL: https://issues.apache.org/jira/browse/ARIES-1715
> Project: Aries
> Issue Type: Bug
> Components: Blueprint
>Affects Versions: blueprint-core-1.8.2, blueprint-core-1.8.0
>Reporter: Daniel Estermann
>Assignee: Dominik Przybysz
>
> Trying to use an injected entity manager in an init-method results in the
> following exception:
> {code}
> 2017-04-12T18:10:24,453 | ERROR | Blueprint Extender: 3 |
> BlueprintContainerImpl | 12 - org.apache.aries.blueprint.core -
> 1.8.0 | Unable to start blueprint container for bundle
> abc.pcta-test/1.0.0.SNAPSHOT
> org.osgi.service.blueprint.container.ComponentDefinitionException: Unable to
> initialize bean testBean
> at
> org.apache.aries.blueprint.container.BeanRecipe.runBeanProcInit(BeanRecipe.java:738)
> [12:org.apache.aries.blueprint.core:1.8.0]
> at
> org.apache.aries.blueprint.container.BeanRecipe.internalCreate2(BeanRecipe.java:848)
> [12:org.apache.aries.blueprint.core:1.8.0]
> at
> org.apache.aries.blueprint.container.BeanRecipe.internalCreate(BeanRecipe.java:811)
> [12:org.apache.aries.blueprint.core:1.8.0]
> at
> org.apache.aries.blueprint.di.AbstractRecipe$1.call(AbstractRecipe.java:79)
> [12:org.apache.aries.blueprint.core:1.8.0]
> at java.util.concurrent.FutureTask.run(FutureTask.java:266) [?:?]
> at
> org.apache.aries.blueprint.di.AbstractRecipe.create(AbstractRecipe.java:88)
> [12:org.apache.aries.blueprint.core:1.8.0]
> at
> org.apache.aries.blueprint.container.BlueprintRepository.createInstances(BlueprintRepository.java:255)
> [12:org.apache.aries.blueprint.core:1.8.0]
> at
> org.apache.aries.blueprint.container.BlueprintRepository.createAll(BlueprintRepository.java:186)
> [12:org.apache.aries.blueprint.core:1.8.0]
> at
> org.apache.aries.blueprint.container.BlueprintContainerImpl.instantiateEagerComponents(BlueprintContainerImpl.java:725)
> [12:org.apache.aries.blueprint.core:1.8.0]
> at
> org.apache.aries.blueprint.container.BlueprintContainerImpl.doRun(BlueprintContainerImpl.java:412)
> [12:org.apache.aries.blueprint.core:1.8.0]
> at
> org.apache.aries.blueprint.container.BlueprintContainerImpl.run(BlueprintContainerImpl.java:277)
> [12:org.apache.aries.blueprint.core:1.8.0]
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) [?:?]
> at java.util.concurrent.FutureTask.run(FutureTask.java:266) [?:?]
> at
> org.apache.aries.blueprint.container.ExecutorServiceWrapper.run(ExecutorServiceWrapper.java:106)
> [12:org.apache.aries.blueprint.core:1.8.0]
> at
> org.apache.aries.blueprint.utils.threading.impl.DiscardableRunnable.run(DiscardableRunnable.java:48)
> [12:org.apache.aries.blueprint.core:1.8.0]
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) [?:?]
> at java.util.concurrent.FutureTask.run(FutureTask.java:266) [?:?]
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
> [?:?]
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
> [?:?]
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> [?:?]
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> [?:?]
> at java.lang.Thread.run(Thread.java:745) [?:?]
> Caused by: java.lang.IllegalStateException: Need active coordination
> at
> org.apache.aries.jpa.support.impl.EMSupplierImpl.get(EMSupplierImpl.java:81)
> ~[?:?]
> at
> org.apache.aries.jpa.support.osgi.impl.EmProxy.invoke(EmProxy.java:38) ~[?:?]
> at com.sun.proxy.$Proxy80.persist(Unknown Source) ~[?:?]
> at Proxya9d42525_1701_4ce9_bbc8_809ae15cb353.persist(Unknown Source)
> ~[?:?]
> at abc.pcta_test.TestBean.init(TestBean.java:28) ~[?:?]
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[?:?]
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> ~[?:?]
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> ~[?:?]
> at
[jira] [Commented] (ARIES-1715) Blueprint doesn't apply interceptors for the init-method.
[
https://issues.apache.org/jira/browse/ARIES-1715?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16176425#comment-16176425
]
Daniel Estermann commented on ARIES-1715:
-
I have found a workaround for this but it's pretty ugly. This:
{code:java}
@PostConstruct
public void init() {
//... do something with an entityManager
}
{code}
...changed to:
{code:java}
@PostConstruct
public void init() {
new Thread() {
@Override
public void run() {
Bundle b = FrameworkUtil.getBundle(MyService.class);
BundleContext bc = b.getBundleContext();
ServiceTracker tr = new
ServiceTracker<>(bc, MyService.class, null);
tr.open();
try
{
MyService self =
tr.waitForService(TimeUnit.SECONDS.toMillis(15));
self.updateProcessingItems();
}
catch (InterruptedException e) { //... }
}
}.start();
}
public void updateProcessingItems() {
//... do something with an entityManager
}
{code}
...should do the job.
> Blueprint doesn't apply interceptors for the init-method.
> -
>
> Key: ARIES-1715
> URL: https://issues.apache.org/jira/browse/ARIES-1715
> Project: Aries
> Issue Type: Bug
> Components: Blueprint
>Affects Versions: blueprint-core-1.8.2, blueprint-core-1.8.0
>Reporter: Daniel Estermann
>
> Trying to use an injected entity manager in an init-method results in the
> following exception:
> {code}
> 2017-04-12T18:10:24,453 | ERROR | Blueprint Extender: 3 |
> BlueprintContainerImpl | 12 - org.apache.aries.blueprint.core -
> 1.8.0 | Unable to start blueprint container for bundle
> abc.pcta-test/1.0.0.SNAPSHOT
> org.osgi.service.blueprint.container.ComponentDefinitionException: Unable to
> initialize bean testBean
> at
> org.apache.aries.blueprint.container.BeanRecipe.runBeanProcInit(BeanRecipe.java:738)
> [12:org.apache.aries.blueprint.core:1.8.0]
> at
> org.apache.aries.blueprint.container.BeanRecipe.internalCreate2(BeanRecipe.java:848)
> [12:org.apache.aries.blueprint.core:1.8.0]
> at
> org.apache.aries.blueprint.container.BeanRecipe.internalCreate(BeanRecipe.java:811)
> [12:org.apache.aries.blueprint.core:1.8.0]
> at
> org.apache.aries.blueprint.di.AbstractRecipe$1.call(AbstractRecipe.java:79)
> [12:org.apache.aries.blueprint.core:1.8.0]
> at java.util.concurrent.FutureTask.run(FutureTask.java:266) [?:?]
> at
> org.apache.aries.blueprint.di.AbstractRecipe.create(AbstractRecipe.java:88)
> [12:org.apache.aries.blueprint.core:1.8.0]
> at
> org.apache.aries.blueprint.container.BlueprintRepository.createInstances(BlueprintRepository.java:255)
> [12:org.apache.aries.blueprint.core:1.8.0]
> at
> org.apache.aries.blueprint.container.BlueprintRepository.createAll(BlueprintRepository.java:186)
> [12:org.apache.aries.blueprint.core:1.8.0]
> at
> org.apache.aries.blueprint.container.BlueprintContainerImpl.instantiateEagerComponents(BlueprintContainerImpl.java:725)
> [12:org.apache.aries.blueprint.core:1.8.0]
> at
> org.apache.aries.blueprint.container.BlueprintContainerImpl.doRun(BlueprintContainerImpl.java:412)
> [12:org.apache.aries.blueprint.core:1.8.0]
> at
> org.apache.aries.blueprint.container.BlueprintContainerImpl.run(BlueprintContainerImpl.java:277)
> [12:org.apache.aries.blueprint.core:1.8.0]
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) [?:?]
> at java.util.concurrent.FutureTask.run(FutureTask.java:266) [?:?]
> at
> org.apache.aries.blueprint.container.ExecutorServiceWrapper.run(ExecutorServiceWrapper.java:106)
> [12:org.apache.aries.blueprint.core:1.8.0]
> at
> org.apache.aries.blueprint.utils.threading.impl.DiscardableRunnable.run(DiscardableRunnable.java:48)
> [12:org.apache.aries.blueprint.core:1.8.0]
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) [?:?]
> at java.util.concurrent.FutureTask.run(FutureTask.java:266) [?:?]
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
> [?:?]
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
> [?:?]
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> [?:?]
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> [?:?]
> at java.lang.Thread.run(Thread.java:745) [?:?]
> Caused by: java.lang.IllegalStateException: Need active coordination
> at
>
[jira] [Updated] (ARIES-1715) Blueprint doesn't apply interceptors for the init-method.
[
https://issues.apache.org/jira/browse/ARIES-1715?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Estermann updated ARIES-1715:
Affects Version/s: blueprint-core-1.8.2
> Blueprint doesn't apply interceptors for the init-method.
> -
>
> Key: ARIES-1715
> URL: https://issues.apache.org/jira/browse/ARIES-1715
> Project: Aries
> Issue Type: Bug
> Components: Blueprint
>Affects Versions: blueprint-core-1.8.2, blueprint-core-1.8.0
>Reporter: Daniel Estermann
>
> Trying to use an injected entity manager in an init-method results in the
> following exception:
> {code}
> 2017-04-12T18:10:24,453 | ERROR | Blueprint Extender: 3 |
> BlueprintContainerImpl | 12 - org.apache.aries.blueprint.core -
> 1.8.0 | Unable to start blueprint container for bundle
> abc.pcta-test/1.0.0.SNAPSHOT
> org.osgi.service.blueprint.container.ComponentDefinitionException: Unable to
> initialize bean testBean
> at
> org.apache.aries.blueprint.container.BeanRecipe.runBeanProcInit(BeanRecipe.java:738)
> [12:org.apache.aries.blueprint.core:1.8.0]
> at
> org.apache.aries.blueprint.container.BeanRecipe.internalCreate2(BeanRecipe.java:848)
> [12:org.apache.aries.blueprint.core:1.8.0]
> at
> org.apache.aries.blueprint.container.BeanRecipe.internalCreate(BeanRecipe.java:811)
> [12:org.apache.aries.blueprint.core:1.8.0]
> at
> org.apache.aries.blueprint.di.AbstractRecipe$1.call(AbstractRecipe.java:79)
> [12:org.apache.aries.blueprint.core:1.8.0]
> at java.util.concurrent.FutureTask.run(FutureTask.java:266) [?:?]
> at
> org.apache.aries.blueprint.di.AbstractRecipe.create(AbstractRecipe.java:88)
> [12:org.apache.aries.blueprint.core:1.8.0]
> at
> org.apache.aries.blueprint.container.BlueprintRepository.createInstances(BlueprintRepository.java:255)
> [12:org.apache.aries.blueprint.core:1.8.0]
> at
> org.apache.aries.blueprint.container.BlueprintRepository.createAll(BlueprintRepository.java:186)
> [12:org.apache.aries.blueprint.core:1.8.0]
> at
> org.apache.aries.blueprint.container.BlueprintContainerImpl.instantiateEagerComponents(BlueprintContainerImpl.java:725)
> [12:org.apache.aries.blueprint.core:1.8.0]
> at
> org.apache.aries.blueprint.container.BlueprintContainerImpl.doRun(BlueprintContainerImpl.java:412)
> [12:org.apache.aries.blueprint.core:1.8.0]
> at
> org.apache.aries.blueprint.container.BlueprintContainerImpl.run(BlueprintContainerImpl.java:277)
> [12:org.apache.aries.blueprint.core:1.8.0]
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) [?:?]
> at java.util.concurrent.FutureTask.run(FutureTask.java:266) [?:?]
> at
> org.apache.aries.blueprint.container.ExecutorServiceWrapper.run(ExecutorServiceWrapper.java:106)
> [12:org.apache.aries.blueprint.core:1.8.0]
> at
> org.apache.aries.blueprint.utils.threading.impl.DiscardableRunnable.run(DiscardableRunnable.java:48)
> [12:org.apache.aries.blueprint.core:1.8.0]
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) [?:?]
> at java.util.concurrent.FutureTask.run(FutureTask.java:266) [?:?]
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
> [?:?]
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
> [?:?]
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> [?:?]
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> [?:?]
> at java.lang.Thread.run(Thread.java:745) [?:?]
> Caused by: java.lang.IllegalStateException: Need active coordination
> at
> org.apache.aries.jpa.support.impl.EMSupplierImpl.get(EMSupplierImpl.java:81)
> ~[?:?]
> at
> org.apache.aries.jpa.support.osgi.impl.EmProxy.invoke(EmProxy.java:38) ~[?:?]
> at com.sun.proxy.$Proxy80.persist(Unknown Source) ~[?:?]
> at Proxya9d42525_1701_4ce9_bbc8_809ae15cb353.persist(Unknown Source)
> ~[?:?]
> at abc.pcta_test.TestBean.init(TestBean.java:28) ~[?:?]
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[?:?]
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> ~[?:?]
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> ~[?:?]
> at java.lang.reflect.Method.invoke(Method.java:498) ~[?:?]
> at
> org.apache.aries.blueprint.utils.ReflectionUtils.invoke(ReflectionUtils.java:299)
> ~[?:?]
> at
> org.apache.aries.blueprint.container.BeanRecipe.invoke(BeanRecipe.java:980)
> ~[?:?]
> at
>
[jira] [Created] (ARIES-1715) Blueprint doesn't apply interceptors for the init-method.
Daniel Estermann created ARIES-1715:
---
Summary: Blueprint doesn't apply interceptors for the init-method.
Key: ARIES-1715
URL: https://issues.apache.org/jira/browse/ARIES-1715
Project: Aries
Issue Type: Bug
Components: Blueprint
Affects Versions: blueprint-core-1.6.2
Reporter: Daniel Estermann
Trying to use an injected entity manager in an init-method results in the
following exception:
{code}
2017-04-12T18:10:24,453 | ERROR | Blueprint Extender: 3 |
BlueprintContainerImpl | 12 - org.apache.aries.blueprint.core - 1.8.0
| Unable to start blueprint container for bundle abc.pcta-test/1.0.0.SNAPSHOT
org.osgi.service.blueprint.container.ComponentDefinitionException: Unable to
initialize bean testBean
at
org.apache.aries.blueprint.container.BeanRecipe.runBeanProcInit(BeanRecipe.java:738)
[12:org.apache.aries.blueprint.core:1.8.0]
at
org.apache.aries.blueprint.container.BeanRecipe.internalCreate2(BeanRecipe.java:848)
[12:org.apache.aries.blueprint.core:1.8.0]
at
org.apache.aries.blueprint.container.BeanRecipe.internalCreate(BeanRecipe.java:811)
[12:org.apache.aries.blueprint.core:1.8.0]
at
org.apache.aries.blueprint.di.AbstractRecipe$1.call(AbstractRecipe.java:79)
[12:org.apache.aries.blueprint.core:1.8.0]
at java.util.concurrent.FutureTask.run(FutureTask.java:266) [?:?]
at
org.apache.aries.blueprint.di.AbstractRecipe.create(AbstractRecipe.java:88)
[12:org.apache.aries.blueprint.core:1.8.0]
at
org.apache.aries.blueprint.container.BlueprintRepository.createInstances(BlueprintRepository.java:255)
[12:org.apache.aries.blueprint.core:1.8.0]
at
org.apache.aries.blueprint.container.BlueprintRepository.createAll(BlueprintRepository.java:186)
[12:org.apache.aries.blueprint.core:1.8.0]
at
org.apache.aries.blueprint.container.BlueprintContainerImpl.instantiateEagerComponents(BlueprintContainerImpl.java:725)
[12:org.apache.aries.blueprint.core:1.8.0]
at
org.apache.aries.blueprint.container.BlueprintContainerImpl.doRun(BlueprintContainerImpl.java:412)
[12:org.apache.aries.blueprint.core:1.8.0]
at
org.apache.aries.blueprint.container.BlueprintContainerImpl.run(BlueprintContainerImpl.java:277)
[12:org.apache.aries.blueprint.core:1.8.0]
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) [?:?]
at java.util.concurrent.FutureTask.run(FutureTask.java:266) [?:?]
at
org.apache.aries.blueprint.container.ExecutorServiceWrapper.run(ExecutorServiceWrapper.java:106)
[12:org.apache.aries.blueprint.core:1.8.0]
at
org.apache.aries.blueprint.utils.threading.impl.DiscardableRunnable.run(DiscardableRunnable.java:48)
[12:org.apache.aries.blueprint.core:1.8.0]
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) [?:?]
at java.util.concurrent.FutureTask.run(FutureTask.java:266) [?:?]
at
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
[?:?]
at
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
[?:?]
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
[?:?]
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
[?:?]
at java.lang.Thread.run(Thread.java:745) [?:?]
Caused by: java.lang.IllegalStateException: Need active coordination
at
org.apache.aries.jpa.support.impl.EMSupplierImpl.get(EMSupplierImpl.java:81)
~[?:?]
at
org.apache.aries.jpa.support.osgi.impl.EmProxy.invoke(EmProxy.java:38) ~[?:?]
at com.sun.proxy.$Proxy80.persist(Unknown Source) ~[?:?]
at Proxya9d42525_1701_4ce9_bbc8_809ae15cb353.persist(Unknown Source)
~[?:?]
at abc.pcta_test.TestBean.init(TestBean.java:28) ~[?:?]
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[?:?]
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
~[?:?]
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
~[?:?]
at java.lang.reflect.Method.invoke(Method.java:498) ~[?:?]
at
org.apache.aries.blueprint.utils.ReflectionUtils.invoke(ReflectionUtils.java:299)
~[?:?]
at
org.apache.aries.blueprint.container.BeanRecipe.invoke(BeanRecipe.java:980)
~[?:?]
at
org.apache.aries.blueprint.container.BeanRecipe.runBeanProcInit(BeanRecipe.java:736)
~[?:?]
... 21 more
{code}
The following example bundle can be used to reproduce it:
https://github.com/Smasherr/postconstruct-transactional-test
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
