[jira] [Updated] (ARIES-1368) BundleResource is not able to compute capabilities for fragments
[ https://issues.apache.org/jira/browse/ARIES-1368?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Ross updated ARIES-1368: - Attachment: OsgiIdentityCapability.OsgiIdentityCapability(Resource,BundleManifest)-CallHierarchy.jpg BundleResource is not able to compute capabilities for fragments Key: ARIES-1368 URL: https://issues.apache.org/jira/browse/ARIES-1368 Project: Aries Issue Type: Bug Components: Subsystem Affects Versions: subsystem-core-1.2.0 Reporter: Wouter Bancken Attachments: OsgiIdentityCapability.OsgiIdentityCapability(Resource,BundleManifest)-CallHierarchy.jpg The computeOsgiIdentityCapability method of the BundleResource is not able to compute capabilities for fragments (only for bundles). This is caused by the fact that the BundleResource is hardcoded to always assume a type of osgi.bundle without inspecting the manifest. Link to mailinglist thread: http://mail-archives.apache.org/mod_mbox/aries-user/201508.mbox/%3CCAL5nZgTOVhdAPYYFOmuV%3DPquAz1a4n_D1Rd3RBrTfu2znCSjKA%40mail.gmail.com%3E -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (ARIES-1368) BundleResource is not able to compute capabilities for fragments
[ https://issues.apache.org/jira/browse/ARIES-1368?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14661827#comment-14661827 ] John Ross commented on ARIES-1368: -- OsgiIdentityCapability.OsgiIdentityCapability(Resource, BundleManifest) will identify all bundles as type osgi.bundle via the osgi.identity capability. For fragments, the type should be osgi.fragment. Looking at the call hierarchy (attached), the evident consequences are the following. (1) Fragments will be misidentified as bundles within the subsystem's local repository. This means fragments will not be discovered within the local repository when searching by osgi.identity requirement. I'm not sure if this is actually ever done as part of installation. (2) Fragments will be misidentified as bundles within the subsystem's Subsystem-Content header if generated by the system rather than supplied by the ESA provider. I do not believe this would affect how the fragment is ultimately installed into the runtime since the framework will generate its own osgi.identity capability. It's not clear to me how this issue would manifest itself at runtime. Wouter, what are the specific symptoms you were experiencing? BundleResource is not able to compute capabilities for fragments Key: ARIES-1368 URL: https://issues.apache.org/jira/browse/ARIES-1368 Project: Aries Issue Type: Bug Components: Subsystem Affects Versions: subsystem-core-1.2.0 Reporter: Wouter Bancken Attachments: OsgiIdentityCapability.OsgiIdentityCapability(Resource,BundleManifest)-CallHierarchy.jpg The computeOsgiIdentityCapability method of the BundleResource is not able to compute capabilities for fragments (only for bundles). This is caused by the fact that the BundleResource is hardcoded to always assume a type of osgi.bundle without inspecting the manifest. Link to mailinglist thread: http://mail-archives.apache.org/mod_mbox/aries-user/201508.mbox/%3CCAL5nZgTOVhdAPYYFOmuV%3DPquAz1a4n_D1Rd3RBrTfu2znCSjKA%40mail.gmail.com%3E -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (ARIES-1368) BundleResource is not able to compute capabilities for fragments
[ https://issues.apache.org/jira/browse/ARIES-1368?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14661848#comment-14661848 ] John Ross commented on ARIES-1368: -- I believe this issue would manifest itself when the Subsystem-Content header is generated by the system and the fragments are provided by a remote repository. The system would be searching for a resource of type osgi.bundle rather than osgi.fragment, and presumably the remote repository would have the correct type. Another manifestation would be when the ESA provider specifies the Subsystem-Content header themselves using the correct type and packages the fragment in the ESA itself. In this case, the system would be searching for a resource of type osgi.fragment, but the type would actually be osgi.bundle in the local repository. I believe everything would work correctly if (1) the Subsystem-Content header is generated by the system, and (2) the fragments are packaged as part of the ESA. BundleResource is not able to compute capabilities for fragments Key: ARIES-1368 URL: https://issues.apache.org/jira/browse/ARIES-1368 Project: Aries Issue Type: Bug Components: Subsystem Affects Versions: subsystem-core-1.2.0 Reporter: Wouter Bancken Attachments: OsgiIdentityCapability.OsgiIdentityCapability(Resource,BundleManifest)-CallHierarchy.jpg The computeOsgiIdentityCapability method of the BundleResource is not able to compute capabilities for fragments (only for bundles). This is caused by the fact that the BundleResource is hardcoded to always assume a type of osgi.bundle without inspecting the manifest. Link to mailinglist thread: http://mail-archives.apache.org/mod_mbox/aries-user/201508.mbox/%3CCAL5nZgTOVhdAPYYFOmuV%3DPquAz1a4n_D1Rd3RBrTfu2znCSjKA%40mail.gmail.com%3E -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[Discuss] Use maven-bundle-plugin (bnd) baseline-mojo instead of our versioning plugin?
Since version 2.5.0 the maven bundle plugin supports bnd baselining. Could use this instead of our custom versioning plugin? The advantage is that we could remove one more generic infrastructure to concentrate better on our core goals of implementing the enterprise specs. See http://svn.apache.org/repos/asf/felix/trunk/bundleplugin/doc/site/baseline-mojo.html Does anyone have experience with it? Christian -- Christian Schneider http://www.liquid-reality.de Open Source Architect http://www.talend.com
[jira] [Resolved] (ARIES-1348) subsystems that are dependencies are not auto started
[ https://issues.apache.org/jira/browse/ARIES-1348?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Watson resolved ARIES-1348. -- Resolution: Fixed Thanks, I released the patch subsystems that are dependencies are not auto started - Key: ARIES-1348 URL: https://issues.apache.org/jira/browse/ARIES-1348 Project: Aries Issue Type: Bug Components: Subsystem Affects Versions: subsystem-2.0.2 Environment: all Reporter: Samuel Bratton Assignee: Thomas Watson Attachments: ARIES-1348.patch Auto start does not work in the following scenario: - bundle a in Feature a (Fa) imports package x - composite b (Cb) exports package x from content bundle b 1) install Cb, install Fa, start Fa start fails with framework resolution error on bundle importing x but 2) install Cb, start Cb, install Fa, start Fa the start works. In case 1) Cb should have it active count incremented and be started automatically per OSGI.cmpn-6.0.0 134.12.2 Active Use Count. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (ARIES-1348) subsystems that are dependencies are not auto started
[ https://issues.apache.org/jira/browse/ARIES-1348?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Watson reassigned ARIES-1348: Assignee: Thomas Watson subsystems that are dependencies are not auto started - Key: ARIES-1348 URL: https://issues.apache.org/jira/browse/ARIES-1348 Project: Aries Issue Type: Bug Components: Subsystem Affects Versions: subsystem-2.0.2 Environment: all Reporter: Samuel Bratton Assignee: Thomas Watson Attachments: ARIES-1348.patch Auto start does not work in the following scenario: - bundle a in Feature a (Fa) imports package x - composite b (Cb) exports package x from content bundle b 1) install Cb, install Fa, start Fa start fails with framework resolution error on bundle importing x but 2) install Cb, start Cb, install Fa, start Fa the start works. In case 1) Cb should have it active count incremented and be started automatically per OSGI.cmpn-6.0.0 134.12.2 Active Use Count. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (ARIES-1368) BundleResource is not able to compute capabilities for fragments
[ https://issues.apache.org/jira/browse/ARIES-1368?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14661899#comment-14661899 ] Tom De Wolf commented on ARIES-1368: John, the problem manifests itself when you use the maven esa plugin and generate an esa in which the fragment is included. Installing such a subsystem does not work as it does not recognize the fragment as fragment. BundleResource is not able to compute capabilities for fragments Key: ARIES-1368 URL: https://issues.apache.org/jira/browse/ARIES-1368 Project: Aries Issue Type: Bug Components: Subsystem Affects Versions: subsystem-core-1.2.0 Reporter: Wouter Bancken Attachments: OsgiIdentityCapability.OsgiIdentityCapability(Resource,BundleManifest)-CallHierarchy.jpg The computeOsgiIdentityCapability method of the BundleResource is not able to compute capabilities for fragments (only for bundles). This is caused by the fact that the BundleResource is hardcoded to always assume a type of osgi.bundle without inspecting the manifest. Link to mailinglist thread: http://mail-archives.apache.org/mod_mbox/aries-user/201508.mbox/%3CCAL5nZgTOVhdAPYYFOmuV%3DPquAz1a4n_D1Rd3RBrTfu2znCSjKA%40mail.gmail.com%3E -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (ARIES-1366) subsystem bundle (uber bundle) exports wrong package versions
[ https://issues.apache.org/jira/browse/ARIES-1366?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Watson closed ARIES-1366. Resolution: Fixed Thanks! I released the patch. subsystem bundle (uber bundle) exports wrong package versions - Key: ARIES-1366 URL: https://issues.apache.org/jira/browse/ARIES-1366 Project: Aries Issue Type: Bug Components: Subsystem Affects Versions: subsystem-2.0.2 Environment: NA Reporter: Samuel Bratton Priority: Minor Attachments: ARIES-1366.patch uber bundle for R6 exports as: org.apache.aries.subsystem;version=1.1 should export as 1.2.0 as the API bundle does. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (ARIES-1369) Transaction is not rolled back if coordination has failed
Christian Schneider created ARIES-1369: -- Summary: Transaction is not rolled back if coordination has failed Key: ARIES-1369 URL: https://issues.apache.org/jira/browse/ARIES-1369 Project: Aries Issue Type: Bug Components: Transaction Affects Versions: transaction-blueprint-1.0.2 Reporter: Christian Schneider Assignee: Christian Schneider Priority: Critical Fix For: transaction-blueprint-1.1.0 If an exception happens in the user code during the transaction then it is possible that this causes the coordination associated to the transaction to fail. In TxInterceptorImpl.postCallWithException we end the coordination before rolling back the transaction. Unfortunately the end method will throw a CoordinationException if the coordination failed. So we exit the interceptor code and never roll back. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (ARIES-1369) Transaction is not rolled back if coordination has failed
[ https://issues.apache.org/jira/browse/ARIES-1369?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schneider updated ARIES-1369: --- Affects Version/s: (was: transaction-blueprint-1.0.2) transaction-blueprint-1.1.0 Transaction is not rolled back if coordination has failed - Key: ARIES-1369 URL: https://issues.apache.org/jira/browse/ARIES-1369 Project: Aries Issue Type: Bug Components: Transaction Affects Versions: transaction-blueprint-1.1.0 Reporter: Christian Schneider Assignee: Christian Schneider Priority: Critical Fix For: transaction-blueprint-1.1.0 If an exception happens in the user code during the transaction then it is possible that this causes the coordination associated to the transaction to fail. In TxInterceptorImpl.postCallWithException we end the coordination before rolling back the transaction. Unfortunately the end method will throw a CoordinationException if the coordination failed. So we exit the interceptor code and never roll back. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (ARIES-1368) BundleResource is not able to compute capabilities for fragments
[
https://issues.apache.org/jira/browse/ARIES-1368?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tom De Wolf updated ARIES-1368:
---
Attachment: test-service-fragment-subsystem-1.0.1-SNAPSHOT.esa
It is the Aries ESA plugin at
http://aries.apache.org/modules/esamavenpluginproject.html
https://github.com/apache/aries/tree/trunk/esa-maven-plugin
Installing the attached subsystem including a fragment with the install gogo
command results in the stacktrace below. Thus the included fragment is not
found. The gogo commands are the ones included in the aries code base at:
https://github.com/apache/aries/tree/trunk/subsystem/subsystem-gogo-command
Cause: OsgiIdentityCapability identifies all bundles as osgi.bundle via the
osgi.identity capability, it should check for fragments and use osgi.fragment.
{code}
install
file:/Users/tom/Downloads/test-service-fragment-subsystem-1.0.1-SNAPSHOT.esa
...
Caused by: org.osgi.service.subsystem.SubsystemException: A required content
resource could not be found. This means the resource was either missing or not
recognized as a supported resource format due to, for example, an invalid
bundle manifest or blueprint XML file. Turn on debug logging for more
information. The resource was:
org.apache.aries.subsystem.core.archive.SubsystemContentRequirement:
namespace=osgi.identity, attributes={},
directives={filter=((osgi.identity=be.aca.test-service-fragment)(type=osgi.fragment)((version=1.0.1.SNAPSHOT)(version=1.0.1.SNAPSHOT)))},
resource=org.apache.aries.subsystem.core.internal.SubsystemResource@9780e9f1
at
org.apache.aries.subsystem.core.internal.SubsystemResource.computeContentResources(SubsystemResource.java:384)
at
org.apache.aries.subsystem.core.internal.SubsystemResource.computeContentResources(SubsystemResource.java:360)
at
org.apache.aries.subsystem.core.internal.SubsystemResource.init(SubsystemResource.java:99)
at
org.apache.aries.subsystem.core.internal.SubsystemResource.init(SubsystemResource.java:92)
at
org.apache.aries.subsystem.core.internal.InstallAction.createSubsystemResource(InstallAction.java:134)
at
org.apache.aries.subsystem.core.internal.InstallAction.run(InstallAction.java:55)
at
org.apache.aries.subsystem.core.internal.InstallAction.run(InstallAction.java:33)
at java.security.AccessController.doPrivileged(Native Method)
at
org.apache.aries.subsystem.core.internal.BasicSubsystem.install(BasicSubsystem.java:621)
at
org.apache.aries.subsystem.core.internal.BasicSubsystem.install(BasicSubsystem.java:259)
at
org.apache.aries.subsystem.core.internal.BasicSubsystem.install(BasicSubsystem.java:63)
... 30 more
g!
{code}
BundleResource is not able to compute capabilities for fragments
Key: ARIES-1368
URL: https://issues.apache.org/jira/browse/ARIES-1368
Project: Aries
Issue Type: Bug
Components: Subsystem
Affects Versions: subsystem-core-1.2.0
Reporter: Wouter Bancken
Attachments:
OsgiIdentityCapability.OsgiIdentityCapability(Resource,BundleManifest)-CallHierarchy.jpg,
test-service-fragment-subsystem-1.0.1-SNAPSHOT.esa
The computeOsgiIdentityCapability method of the BundleResource is not able to
compute capabilities for fragments (only for bundles).
This is caused by the fact that the BundleResource is hardcoded to always
assume a type of osgi.bundle without inspecting the manifest.
Link to mailinglist thread:
http://mail-archives.apache.org/mod_mbox/aries-user/201508.mbox/%3CCAL5nZgTOVhdAPYYFOmuV%3DPquAz1a4n_D1Rd3RBrTfu2znCSjKA%40mail.gmail.com%3E
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (ARIES-1368) BundleResource is not able to compute capabilities for fragments
[ https://issues.apache.org/jira/browse/ARIES-1368?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14662200#comment-14662200 ] John Ross commented on ARIES-1368: -- Thanks, Tom. If you look at OSGI-INF/SUBSYSTEM.MF contained within your attached ESA file, you will see the following: Subsystem-Content: be.aca.test-service-fragment;type=osgi.fragment;version=[1.0.1.SNAPSHOT,1.0.1.SNAPSHOT];start-order:=1 It is the declaration of the type, which I emphasize is correct, that is causing the issue in your case, which corresponds to (2) in my previous comment of https://issues.apache.org/jira/browse/ARIES-1368?focusedCommentId=14661827page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14661827. I presume this is being generated by the plugin. A workaround would be to either remove the type from Subsystem-Content or the entire header itself; however, this will be fixed as part of a future release. For example, the following modification should work: Subsystem-Content: be.aca.test-service-fragment;version=[1.0.1.SNAPSHOT,1.0.1.SNAPSHOT];start-order:=1 BundleResource is not able to compute capabilities for fragments Key: ARIES-1368 URL: https://issues.apache.org/jira/browse/ARIES-1368 Project: Aries Issue Type: Bug Components: Subsystem Affects Versions: subsystem-core-1.2.0 Reporter: Wouter Bancken Attachments: OsgiIdentityCapability.OsgiIdentityCapability(Resource,BundleManifest)-CallHierarchy.jpg, test-service-fragment-subsystem-1.0.1-SNAPSHOT.esa The computeOsgiIdentityCapability method of the BundleResource is not able to compute capabilities for fragments (only for bundles). This is caused by the fact that the BundleResource is hardcoded to always assume a type of osgi.bundle without inspecting the manifest. Link to mailinglist thread: http://mail-archives.apache.org/mod_mbox/aries-user/201508.mbox/%3CCAL5nZgTOVhdAPYYFOmuV%3DPquAz1a4n_D1Rd3RBrTfu2znCSjKA%40mail.gmail.com%3E -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (ARIES-1368) BundleResource is not able to compute capabilities for fragments
[ https://issues.apache.org/jira/browse/ARIES-1368?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14662230#comment-14662230 ] Tom De Wolf commented on ARIES-1368: Ok, thank you for explaining this. When can we expect to have the fix for this integrated in a new version of the subsystems library? The workaround would imply manually writing out subsystem manifests and no longer generate them using the maven plugin which we would like to keep. BundleResource is not able to compute capabilities for fragments Key: ARIES-1368 URL: https://issues.apache.org/jira/browse/ARIES-1368 Project: Aries Issue Type: Bug Components: Subsystem Affects Versions: subsystem-core-1.2.0 Reporter: Wouter Bancken Attachments: OsgiIdentityCapability.OsgiIdentityCapability(Resource,BundleManifest)-CallHierarchy.jpg, test-service-fragment-subsystem-1.0.1-SNAPSHOT.esa The computeOsgiIdentityCapability method of the BundleResource is not able to compute capabilities for fragments (only for bundles). This is caused by the fact that the BundleResource is hardcoded to always assume a type of osgi.bundle without inspecting the manifest. Link to mailinglist thread: http://mail-archives.apache.org/mod_mbox/aries-user/201508.mbox/%3CCAL5nZgTOVhdAPYYFOmuV%3DPquAz1a4n_D1Rd3RBrTfu2znCSjKA%40mail.gmail.com%3E -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (ARIES-1368) BundleResource is not able to compute capabilities for fragments
[ https://issues.apache.org/jira/browse/ARIES-1368?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14662252#comment-14662252 ] John Ross commented on ARIES-1368: -- Wouter indicated version subsystem-core-1.2.0, although this issue affects all currently released versions. The current release is version subsystem-core-2.0.2. The next release from trunk would be subsystem-core-2.0.3 or subsystem-core-2.1.0 depending on the scope of other fixed defects that would be included. Is there any reason you could not move up to the latest release? BundleResource is not able to compute capabilities for fragments Key: ARIES-1368 URL: https://issues.apache.org/jira/browse/ARIES-1368 Project: Aries Issue Type: Bug Components: Subsystem Affects Versions: subsystem-core-1.2.0 Reporter: Wouter Bancken Attachments: OsgiIdentityCapability.OsgiIdentityCapability(Resource,BundleManifest)-CallHierarchy.jpg, test-service-fragment-subsystem-1.0.1-SNAPSHOT.esa The computeOsgiIdentityCapability method of the BundleResource is not able to compute capabilities for fragments (only for bundles). This is caused by the fact that the BundleResource is hardcoded to always assume a type of osgi.bundle without inspecting the manifest. Link to mailinglist thread: http://mail-archives.apache.org/mod_mbox/aries-user/201508.mbox/%3CCAL5nZgTOVhdAPYYFOmuV%3DPquAz1a4n_D1Rd3RBrTfu2znCSjKA%40mail.gmail.com%3E -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (ARIES-1369) Transaction is not rolled back if coordination has failed
[ https://issues.apache.org/jira/browse/ARIES-1369?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schneider updated ARIES-1369: --- Fix Version/s: transaction-blueprint-1.1.1 Transaction is not rolled back if coordination has failed - Key: ARIES-1369 URL: https://issues.apache.org/jira/browse/ARIES-1369 Project: Aries Issue Type: Bug Components: Transaction Affects Versions: transaction-blueprint-1.1.0 Reporter: Christian Schneider Assignee: Christian Schneider Priority: Critical Fix For: transaction-blueprint-1.1.1 If an exception happens in the user code during the transaction then it is possible that this causes the coordination associated to the transaction to fail. In TxInterceptorImpl.postCallWithException we end the coordination before rolling back the transaction. Unfortunately the end method will throw a CoordinationException if the coordination failed. So we exit the interceptor code and never roll back. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Re: [VOTE] Transaction manager 1.3.0, transaction blueprint 1.1.0, jpa 2.1.0
I just found and fixed a critical bug in transaction-blueprint 1.1.0. See https://issues.apache.org/jira/browse/ARIES-1369 I would like to keep the vote up as the other releases should be fine and will just release transaction-blueprint 1.1.1 too. Is that ok with all of you? Christian On 06.08.2015 09:49, Christian Schneider wrote: I've staged a release for vote at: https://repository.apache.org/content/repositories/orgapachearies-1033 In transaction manager there is just a bug fix. I removed the jta API from the bundle. So it has to be installed separately now. The advantage is that we do not have refreshs of bundles depending on jta anymore. For transaction blueprint and jpa the biggest change is that we now use the Coordinator service to manage the lifecycle of the EnityManager. So there is no need anymore for the preCall and postCall methods of EmSupplier which did this job before. I deprecated the methods and they only have empty methods as impl now (This is an incompatibility for people who used these methods directly). The big advantage is that non blueprint code can now define the lifecycle using a standard API that does not depend on Aries. For transaction blueprint we now also support the JTA 1.2 @Transactional annotation. Together with @PersistenceContext this now allows a purely standard annotation based configuration of jpa beans. So the user code does not need to depend on Aries. Additionally @Transaction(TxType.SUPPORTS) now starts a coordination even if there is no transaction. So thiARIES-1369 https://issues.apache.org/jira/browse/ARIES-1369s can be used to extend the lifecycle of the EntityManager to any code even outside the persistence layer without managing a coordination by hand. *Release Notes - Aries - Version transaction-manager-1.3.0* ** Bug * [ARIES-1364] - transaction.manager causes cascading refreshs in karaf 4 https://issues.apache.org/jira/browse/ARIES/fixforversion/12333144 *Release Notes - Aries - Version transaction-blueprint-1.1.0* ** Bug * [ARIES-1361] - EntityManager does not participate in transaction if transactional interceptor is called after jpa interceptor ** Dependency upgrade * [ARIES-1296] - Upgrade to transaction api 1.2 ** Improvement * [ARIES-1347] - Working example of @Transaction annotation ** New Feature * [ARIES-628] - Support JTA attributes by annotations * [ARIES-1362] - Support coordinations triggered by transaction markers https://issues.apache.org/jira/browse/ARIES/fixforversion/12333049 *Release Notes - Aries - Version jpa-2.1.0* ** Bug * [ARIES-736] - Aries does not take into account the concept of complete/incomplete Persistence Units * [ARIES-1349] - EmfProxy.close should close tracker instead of EMF * [ARIES-1351] - TCK tests not working ** Improvement * [ARIES-1343] - Also scan parent classes for jpa annotations * [ARIES-1344] - Support multiple EntityManager injections per class * [ARIES-1345] - Support jpa annotations on method and class * [ARIES-1346] - EntityManager should be reused for series of coordinated calls https://issues.apache.org/jira/browse/ARIES/fixforversion/12332801 Please review and vote: [ ] +1 Release the above artifacts [ ] -1 Do not Here is my +1 Cheers, Christian -- Christian Schneider http://www.liquid-reality.de Open Source Architect http://www.talend.com -- Christian Schneider http://www.liquid-reality.de Open Source Architect http://www.talend.com
[jira] [Resolved] (ARIES-1369) Transaction is not rolled back if coordination has failed
[ https://issues.apache.org/jira/browse/ARIES-1369?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schneider resolved ARIES-1369. Resolution: Fixed Transaction is not rolled back if coordination has failed - Key: ARIES-1369 URL: https://issues.apache.org/jira/browse/ARIES-1369 Project: Aries Issue Type: Bug Components: Transaction Affects Versions: transaction-blueprint-1.1.0 Reporter: Christian Schneider Assignee: Christian Schneider Priority: Critical Fix For: transaction-blueprint-1.1.1 If an exception happens in the user code during the transaction then it is possible that this causes the coordination associated to the transaction to fail. In TxInterceptorImpl.postCallWithException we end the coordination before rolling back the transaction. Unfortunately the end method will throw a CoordinationException if the coordination failed. So we exit the interceptor code and never roll back. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (ARIES-1369) Transaction is not rolled back if coordination has failed
[ https://issues.apache.org/jira/browse/ARIES-1369?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schneider updated ARIES-1369: --- Fix Version/s: (was: transaction-blueprint-1.1.0) Transaction is not rolled back if coordination has failed - Key: ARIES-1369 URL: https://issues.apache.org/jira/browse/ARIES-1369 Project: Aries Issue Type: Bug Components: Transaction Affects Versions: transaction-blueprint-1.1.0 Reporter: Christian Schneider Assignee: Christian Schneider Priority: Critical If an exception happens in the user code during the transaction then it is possible that this causes the coordination associated to the transaction to fail. In TxInterceptorImpl.postCallWithException we end the coordination before rolling back the transaction. Unfortunately the end method will throw a CoordinationException if the coordination failed. So we exit the interceptor code and never roll back. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Re: [VOTE] Release Aries Asynchronous OSGi Services 1.0.1
+1 Dan On Aug 6, 2015, at 7:46 AM, dav...@apache.org wrote: Hi all, I'm calling a vote on the first release of the Aries Asynchronous OSGi Services implementation. The release has number 1.0.1 as the previous vote was cancelled. This implements the OSGi Asynchronous Services specification (chapter 138) and the OSGi Promises specification (chapter 705) of the OSGi Enterprise R6 specifications, which were released yesterday [1] Staging repository: https://repository.apache.org/content/repositories/orgapachearies-1034 For details on getting started see http://aries.apache.org/modules/async-svcs.html Please vote: +1 Approve the release -1 Do not approve the release (please explain why) This vote will be open for at least 72 hours. Best regards, David Bosschaert [1] http://www.osgi.org/Download/Release6 -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
[jira] [Commented] (ARIES-1368) BundleResource is not able to compute capabilities for fragments
[ https://issues.apache.org/jira/browse/ARIES-1368?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14662280#comment-14662280 ] John Ross commented on ARIES-1368: -- I've written a test case that reproduces the second manifestation referenced in comment https://issues.apache.org/jira/browse/ARIES-1368?focusedCommentId=14661848page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14661848. The issue cannot be reproduced unless the Subsystem-Content header with a declared type of osgi.fragment is explicitly provided. I will also implement a test case for the first manifestation mentioned in that same comment. BundleResource is not able to compute capabilities for fragments Key: ARIES-1368 URL: https://issues.apache.org/jira/browse/ARIES-1368 Project: Aries Issue Type: Bug Components: Subsystem Affects Versions: subsystem-core-1.2.0 Reporter: Wouter Bancken Attachments: OsgiIdentityCapability.OsgiIdentityCapability(Resource,BundleManifest)-CallHierarchy.jpg, test-service-fragment-subsystem-1.0.1-SNAPSHOT.esa The computeOsgiIdentityCapability method of the BundleResource is not able to compute capabilities for fragments (only for bundles). This is caused by the fact that the BundleResource is hardcoded to always assume a type of osgi.bundle without inspecting the manifest. Link to mailinglist thread: http://mail-archives.apache.org/mod_mbox/aries-user/201508.mbox/%3CCAL5nZgTOVhdAPYYFOmuV%3DPquAz1a4n_D1Rd3RBrTfu2znCSjKA%40mail.gmail.com%3E -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (ARIES-1368) BundleResource is not able to compute capabilities for fragments
[ https://issues.apache.org/jira/browse/ARIES-1368?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14662324#comment-14662324 ] John Ross commented on ARIES-1368: -- I've implemented the second test case and it fails as expected. BundleResource is not able to compute capabilities for fragments Key: ARIES-1368 URL: https://issues.apache.org/jira/browse/ARIES-1368 Project: Aries Issue Type: Bug Components: Subsystem Affects Versions: subsystem-core-1.2.0 Reporter: Wouter Bancken Attachments: OsgiIdentityCapability.OsgiIdentityCapability(Resource,BundleManifest)-CallHierarchy.jpg, test-service-fragment-subsystem-1.0.1-SNAPSHOT.esa The computeOsgiIdentityCapability method of the BundleResource is not able to compute capabilities for fragments (only for bundles). This is caused by the fact that the BundleResource is hardcoded to always assume a type of osgi.bundle without inspecting the manifest. Link to mailinglist thread: http://mail-archives.apache.org/mod_mbox/aries-user/201508.mbox/%3CCAL5nZgTOVhdAPYYFOmuV%3DPquAz1a4n_D1Rd3RBrTfu2znCSjKA%40mail.gmail.com%3E -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Re: [Discuss] Use maven-bundle-plugin (bnd) baseline-mojo instead of our versioning plugin?
Am 07.08.15 um 09:47 schrieb Christian Schneider: Since version 2.5.0 the maven bundle plugin supports bnd baselining. Could use this instead of our custom versioning plugin? The advantage is that we could remove one more generic infrastructure to concentrate better on our core goals of implementing the enterprise specs. See http://svn.apache.org/repos/asf/felix/trunk/bundleplugin/doc/site/baseline-mojo.html Does anyone have experience with it? We're using this a lot and it works perfectly :) Carsten -- Carsten Ziegeler Adobe Research Switzerland cziege...@apache.org
