Hi, I'm afraid I haven't had time to do a full review, but from the log I see that your datasource services are both being registered by blueprint using the DataSource interface.
Unless you're enlisting the JTA datasource with transactions yourself then this looks like the source of the problem. If you want the Aries runtime to do the enlistment then you need to register the datasource as an XADataSource. There are then two options: 1. You can let the transaction wrappers bundle do the enlistment and add (xa=true) to your JTA-data-source jndi name 2. You can let the JPA container do the enlistment by changing the JTA-data-source jndi name to use XADataSource as the interface. This will only work for Aries JPA 1.0 and higher. If you are after more information about setting up OSGi applications with JPA then there's a whole chapter about it in Enterprise OSGi in Action, along with chapters about tools, testing, web applications and remoting. You can get it at http://www.manning.com/cummins and get 37% off using the code eosgi37. I hope this helps you get set up ok. Regards, Tim Date: Mon, 15 Oct 2012 01:55:59 +1030 From: a...@solveitsoftware.com To: user@aries.apache.org Subject: Re: Aries eclipselink.adapter Thank you, Timothy. I use the current release 1.0.0 of aries http://aries.apache.org/downloads/currentrelease.html I have attached the blueprint context files - blueprint seems to be the only way at the moment to use declarative, AOP style, transactions support. And the test class invoked in blueprint-test.xml blueprint-datasource.xml -- blueprint context of the database bundle blueprint-employee.xml - blueprint of employee bundle blueprint-test - blueprint of the integration test routines bundle persistence-jta.xml - the JPA/JTA persistence unit configuration I must confess, that I don't know what is auto-enlisting datasource. Regards, Anatoly PS I also attached the log of the test with the deliberately induced sql error. The rollback is announced, but all the insert statements, except for the offending one, still get committed, including the cascade insertions. So, no actual rollback is performed. On 12/10/2012 9:40 PM, Timothy Ward wrote: Hi Anatoly, I'd be interested in seeing the configuration for the transactions that failed to roll back, and in knowing what version of Aries JPA you were using. If you don't give the JPA container an auto-enlisting datasource then you can end up with non-transactional behaviour. This is why we have the transaction-wrappers bundle. Tim > Date: Fri, 12 Oct 2012 09:46:39 +1030 > From: a...@solveitsoftware.com > To: user@aries.apache.org > Subject: Re: Aries eclipselink.adapter > > Yeah, that's what I did a month ago: > > ~/projects/aries/jpa/jpa-container-eclipselink-adapter > --- pom.xml (revision 1388340) > +++ pom.xml (working copy) > @@ -81,7 +81,10 @@ > <dependency> > <groupId>org.apache.aries</groupId> > <artifactId>org.apache.aries.util</artifactId> > + <version>1.0.0</version> > +<!-- > <version>0.4</version> > +--> > <scope>provided</scope> > </dependency> > </dependencies> > > Still, the transactions don't work as expected neither with eclipselink > nor with openjpa. > For instance, if two methods participate in the transaction (the same of > tx id testified that that was the case), > and the second fails, then the first one still got committed. > The message was that transaction is nominated to rollback, but then > Rollback exception followed. > > I send the message some time ago to the user list asking if anyone knows > why the eclipse link adapter has never been included into the release. > And what the actual status of it. > Anyway, as far as my experience go the the aries container failed for me > on transactional support. > > > On 11/10/2012 8:51 PM, Christian Eugster wrote: > > Hi, > > > > I managed this by changing the version range of aries.util in the pom. > > > > But now I have another problem. After packaging I tried to run an > > example in the osgi-container. I get a ComponentDefinitionException > > saying Unable to validate xml: Caused by SAXParseException saying: > > cvc-complex-type.2.3: Element 'blueprint' cannot have character > > [children], because the type's content is element-only. > > > > My blueprint looks like following: > > > > <?xml version="1.0" encoding="utf-8"?> > > <blueprint xmlns="http://www.osgi.org/xmlns/blueprint/v1.0.0"; > > xmlns:tx="http://aries.apache.org/xmlns/transactions/v1.0.0"; > > xmlns:jpa="http://aries.apache.org/xmlns/jpa/v1.1.0";> > > > > > <bean > > id="testDAOBean" > > class="ch.persistence.TestDAOImpl" > > > > > <tx:transaction method="*" value="Required"/> > > <jpa:context property="em" unitname="herakles"/> > > </bean> > > </blueprint> > > > > as I see, there are no character children. But what am I doing wrong? > > > > Thank you for help! > > > > > > > > > -- > Anatoly Osiko > Software Engineer, Integration > SolveIT Software Pty Ltd > > Adelaide | Brisbane | Chisinau | Melbourne | Perth > > D: +61 8 7071 4918 > T: +61 8 8221 5533 > M: +61 4 1980 0386 > F: +61 8 8221 5677 > > SolveIT Software Building > Level 1, 99 Frome Street, > Adelaide, SA 5000 > > www.SolveITSoftware.com > > -- Anatoly Osiko Software Engineer, Integration SolveIT Software Pty Ltd Adelaide | Brisbane | Chisinau | Melbourne | Perth D: +61 8 7071 4918 T: +61 8 8221 5533 M: +61 4 1980 0386 F: +61 8 8221 5677 SolveIT Software Building Level 1, 99 Frome Street, Adelaide, SA 5000 www.SolveITSoftware.com
