Thanks Brian,
I can get the transaction manager to start correctly by including the
geronimo-jta_1.1_spec-1.1.1.jar in the Xbootclasspath as you mention but
something still isn't right when I actually attempt to use a container
managed transaction via the blueprint declarative transaction support.
It seems that something isn't being registered correctly.
I get this error:
Caused by: javax.persistence.TransactionRequiredException: No JTA
transaction services implementation is currently available. As a result
the JPA container cannot integrate with JTA transactions.
at
org.apache.aries.jpa.container.context.transaction.impl.JTAPersistenceContextRegistry.getCurrentPersistenceContext(JTAPersistenceContextRegistry.java:96)
at
org.apache.aries.jpa.container.context.transaction.impl.JTAEntityManager.getPersistenceContext(JTAEntityManager.java:73)
at
org.apache.aries.jpa.container.context.transaction.impl.JTAEntityManager.persist(JTAEntityManager.java:220)
at
org.apache.aries.samples.ariestrader.persist.jpa.TradeJpaCm.createQuote(TradeJpaCm.java:449)
... 31 more
java.lang.RuntimeException:
javax.persistence.TransactionRequiredException: No JTA transaction
services implementation is currently available. As a result the JPA
container cannot integrate with JTA transactions.
at
org.apache.aries.samples.ariestrader.persist.jpa.TradeJpaCm.createQuote(TradeJpaCm.java:458)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
Joe
Brian De Pradine wrote:
Hi Joe,
The main change to the transaction implementation is that the
org.apache.aries.transaction.manager bundle no longer exports the
javax.transaction and javax.transaction.xa packages. This means that in
order to use transactions you now need to add the
geronimo-jta_1.1_spec-1.1.1.jar to the bootclasspath. The reason that this
is necessary is that the system bundle also has some classes from the
javax.transaction and javax.transaction.xa packages and using those
classes results in errors similar to the following:
java.lang.LinkageError: loader constraint violation: when resolving
interface method
"javax.sql.XAConnection.getXAResource()Ljavax/transaction/xa/XAResource;"
the class loader (instance of
org/eclipse/osgi/internal/baseadaptor/DefaultClassLoader) of the current
class, org.apache.aries.transaction.jdbc.ConnectionWrapper, and the class
loader (instance of <bootloader>) for resolved class,
javax/sql/XAConnection, have different Class objects for the type
javax/transaction/xa/XAResource used in the signature
You probably haven't seen this exception before when running the Aries
Trader application because the code to enlist JDBC resources in
transactions is also included in the same patch.
On 4 March 2010 18:06, Joe Bohn <[email protected]> wrote:
Hi Alasdair,
Thanks. ?I'm sorry if my note sounded a little terse and you thought I
was
complaining about the jndi issue (or even the transaction issue for that
matter). ?That was not what I intended to convey.
My note was more driven by confusion related to transaction support. ?I
just
confirmed (at least as far as I understand how to do) that AriesTrader
transaction support was working prior to the recent changes. ?However,
I've
heard comments that it should not have been working. And so I was trying
to
get a better understanding of why it was working before and if the
recent
changes (which now require adding the geronimo jta spec to the
Xbootclasspath) were really necessary.
The jndi change was really just mentioned because you can't get far
enough
in AriesTrader to see transaction working unless you also revert the
jndi
change locally which will let you get far enough to see it working with
the
former transaction code.
Cheers
Brian DePradine
Web Services Development
IBM Hursley
External +44 (0) 1962 816319 Internal 246319
If you can't find the time to do it right the first time, where will you
find the time to do it again?
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number
741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
--
Joe
