In which case it is starting to sound as though there might be a problem with
the db driver. Have you tried it with derby or similar?
Tim
Date: Sun, 21 Oct 2012 00:49:14 +1030
From: a...@solveitsoftware.com
To: user@aries.apache.org
Subject: Re: Aries eclipselink.adapter
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: a...@solveitsoftware.com
To: user@aries.apache.org
Subject: Re: Aries eclipselink.adapter
... my progress so far :
With this line in the persistence.xml
<jta-data-source>osgi:service/javax.sql.DataSource/(&(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: a...@solveitsoftware.com
To: user@aries.apache.org
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: a...@solveitsoftware.com
To: 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
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
--
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
--
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
