Good on you, Christian.
Did you also run a transaction test? I mean with one faulty statement that should cause all the other participating transactions rollback?

Alas, my problem appears to be in the support (rather lack of this) from MsSql or jtds driver.

Frankly speaking I find this practice of manually creating the list for org.osgi.framework.system.packages is a doubtful practice. May be there is some option in eclipse/equinox to create it, but I didn't find it. I still use the generated config.ini.

My class loader error I resolved by excluding javax.transaction bundle from the runtime (it was contained in the eclipse's plugins)

Regards,
Anatoly


On 22/10/2012 6:07 PM, Christian Eugster wrote:
Hi Anatoly,

Today I succeeded lastly to save an entity in my testenvironment with following configuration:

I did not use the ...(xa=true)) in the persistence.xml file.
I startet my test environment that failed to save an entity.
Then I copied the generated config.ini file in another (save from beeing deleted) place. In that file I copied the whole section of org.osgi.framework.system.packages=... (javax.transaction.. including) from the file proposed by Tim. Then I changed the run configuration of my test environment (section Configuration) by defining "Use an existing config.ini file as a template" pointing to the changed config.ini file (see above).

Running this configuration did it.

Regards

Christian

Am 20.10.12 13:31, schrieb Anatoly Osiko:
Shame on me, of course,  it's LDAP. I'll correct it.

Alas, the easiest option 2) didn't work - I sent a separate message on that.

Thank you.
Regards,
Anatoly.

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

The bit in brackets for the jndi name is an ldap filter (just like a service lookup). What you want is

(&(osgi.jndi.service.name=jpa/jtaStagingDb)(xa=true))

You don't need to add <entry key="xa" value="true" /> to your service export, that gets added by the transaction wrappers bundle when it re-exports your service (to let you know it's the wrapped one).

I think the easiest setup for you is to use:

<jta-data-source>osgi:service/javax.sql.XADataSource/(osgi.jndi.service.name=jpa/jtaStagingDb)</jta-data-source>


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


Regards,

Tim

------------------------------------------------------------------------
Date: Sat, 20 Oct 2012 21:29:53 +1030
From: a...@solveitsoftware.com
To: user@aries.apache.org
Subject: Re: Aries eclipselink.adapter

While you are still on-line, may I ask you for some clarifications;

persistence.xml: the following apparently doesn't work:
<jta-data-source>osgi:service/javax.sql.DataSource/(osgi.jndi.service.name=jpa/jtaStagingDb xa=true)</jta-data-source>

datasource blueprint? : neither this
 <service id="xaDataSource" ref="stagingXADataSource"
    interface="javax.sql.DataSource">
    <service-properties>
      <entry key="osgi.jndi.service.name" value="jpa/jtaStagingDb" />
      <entry key="xa" value="true" />
    </service-properties>
  </service>


What's the correct syntax?

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: a...@solveitsoftware.com <mailto:a...@solveitsoftware.com>
    To: user@aries.apache.org <mailto:user@aries.apache.org>
    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: a...@solveitsoftware.com <mailto:a...@solveitsoftware.com>
        To: user@aries.apache.org <mailto: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
            <mailto:a...@solveitsoftware.com>
            > To: user@aries.apache.org <mailto: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";
            <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




--
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