Yes.

On 21/10/2012 12:48 AM, Timothy Ward wrote:
This was in addition to changing your datasource blueprint to:

 <service id="xaDataSource" ref="stagingXADataSource"
    interface="javax.sql.XADataSource">
    <service-properties>
      <entry key="osgi.jndi.service.name" value="jpa/jtaStagingDb" />
  </service-properties>
</service>

wasn't it?

Tim

------------------------------------------------------------------------
Date: Sun, 21 Oct 2012 00:02:21 +1030
From: [email protected]
To: [email protected]
Subject: Re: Aries eclipselink.adapter

... my progress so far :

With this line in the persistence.xml
 
<jta-data-source>osgi:service/javax.sql.DataSource/(&amp;(osgi.jndi.service.name=jpa/jtaStagingDb)(xa=true))</jta-data-source>

Yet, the result is still as before: all the participating transactions apart from the offending one got commited.

My only choice is to MsSql, and the problem might be with the driver.
Of course, I might try to build the test case with other database to verify this.

As for the latest suggestions to tweak the config.ini ... This one is generated (Eclipse default option: generate with default content) and
doesn't bother to specify the org.osgi.framework.system.packages property.
I definitely not going to create that listing manually - it's crazy.

At this very moment I tend to point finger to MsSql ...

Regards,
Anatoly

On 20/10/2012 10:43 PM, Timothy Ward wrote:

    Hi,

    Have you set up your system packages to prevent people getting
    wired to the split package in the JDK?

    If you look at
    
https://svn.apache.org/repos/asf/aries/trunk/samples/blog/blog-assembly/src/main/filtered-resources/configuration/config.ini

    You can see that the org.osgi.framework.system.packages property
    sets a mandatory partial=true parameter on javax.transaction and
    javax.transaction.xa

    Regards,

    Tim

    ------------------------------------------------------------------------
    Date: Sat, 20 Oct 2012 21:37:05 +1030
    From: [email protected] <mailto:[email protected]>
    To: [email protected] <mailto:[email protected]>
    Subject: Re: Aries eclipselink.adapter

    I tried the option 2) - I recollect tried it some time before.
    And now it also doesn't work - problem with MsSql driver

    Caused by: java.lang.LinkageError: loader constraint violation in
    interface itable initialization: when resolving method
    
"net.sourceforge.jtds.jdbcx.JtdsXAConnection.getXAResource()Ljavax/transaction/xa/XAResource;"
    the class loader (instance of
    org/eclipse/osgi/internal/baseadaptor/DefaultClassLoader) of the
    current class, net/sourceforge/jtds/jdbcx/JtdsXAConnection, and
    the class loader (instance of <bootloader>) for interface
    javax/sql/XAConnection have different Class objects for the type
    javax/transaction/xa/XAResource used in the signature
        at
    
net.sourceforge.jtds.jdbcx.JtdsDataSource.getXAConnection(JtdsDataSource.java:116)
        at
    
org.apache.aries.transaction.jdbc.XADatasourceEnlistingWrapper.getConnection(XADatasourceEnlistingWrapper.java:63)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)

    So, the ball on the MsSql driver side? The bad news is that I am
    not aware of any other driver, and that one worked perfectly well
    with Spring framework JTA declarative support in non-OSGi environment.

    What do you think?

    On 20/10/2012 9:25 PM, Timothy Ward wrote:

        I'm glad I could help!

        I'll check with Manning about the discount code, I wasn't
        aware that it had an expiry date.

        Regards,

        Tim

        ------------------------------------------------------------------------
        Date: Sat, 20 Oct 2012 21:08:05 +1030
        From: [email protected] <mailto:[email protected]>
        To: [email protected] <mailto:[email protected]>
        Subject: Re: Aries eclipselink.adapter

        Hi, Timothy.

        Thank you, your message arrived very handy just when I am
        wasting my Saturday night (UTC +9.30) in another attempt to
        make JTA work.
        For a more than a couple of week I put it on the back burner,
        while doing other tasks.
        I will look at your suggestions and also will purchase the
        book - thanks for the generous offer. I had only green paper
        and the source code so far.
        So, I may want to ask for an autograph from the author :).

        My OSGi crash course is lasting couple of month by now, so I
        had only chance to digest (albeit still suffering heartburn :)
        ) "OSGi in Action".
        Though I realized at rather early stage that I have to deal
        with OSGi enterprise as far as JPA/JTA container support
        concerned.

        Kind regards,
        Anatoly

        PS "The coupon code you have entered has expired" I received
        this message when applied the code.


        On 20/10/2012 8:25 PM, Timothy Ward wrote:

            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: [email protected] <mailto:[email protected]>
            To: [email protected] <mailto:[email protected]>
            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: [email protected]
                <mailto:[email protected]>
                > To: [email protected] <mailto:[email protected]>
                > 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";
                <http://www.osgi.org/xmlns/blueprint/v1.0.0>
                > >
                xmlns:tx="http://aries.apache.org/xmlns/transactions/v1.0.0";
                <http://aries.apache.org/xmlns/transactions/v1.0.0>
                > >
                xmlns:jpa="http://aries.apache.org/xmlns/jpa/v1.1.0";
                <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 <http://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 <http://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 <http://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 <http://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 <http://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