Simply export your datasource service using the XADataSource interface, and 
import it with a jndi name like:

osgi:service/javax.sql.XADataSource/(foo=bar)

The JPA container will detect the XA interface and do the wrapping 
automatically.

Date: Sat, 20 Oct 2012 15:25:20 +0200
From: christian.eugs...@gmx.net
To: user@aries.apache.org
Subject: Re: Aries eclipselink.adapter


  
    
  
  
    Hi Tim, thank you for your considerations. I have ordered the
      book some time ago but I am still waiting for it to arrive. To
      your proposes: I would like to have the JPA container do the enlistment.
      How do I achieve this?

      

      Thanks!

      

      Christian

      

    
    Am 20.10.12 11:55, schrieb Timothy
      Ward:

    
    
      
      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 



      
    
    

  

                                          

Reply via email to