Hi, Timothy.
Thanks again for your guidance.
I fixed the reported loader violation error by removing
javax.transaction (1.1.1.v201105210645) bundle from the runtime
configuration: it's in eclipse's
plugins/javax.transaction_1.1.1.v201105210645.jar
Now I am looking at MsSql server XA support, and this may be the problem
for the kind of server we use.
I wonder if the distributed tx support is a prerequisite for the aries
transaction container. We don't have distributed transactions - there is
only one datasource. Can it work with just javax.sql.DataSource?
BTW, I purchased the e version of the Enterprise OSGi in Action using
Manning's current promotional code *o1942.
*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 <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
