Re: AriesTrader used to work ...

[Joe Bohn]

Thanks!  I validated that this resolves the issues again for AriesTrader 
and hopefully enlists the DataSource in the transaction as well (I still 
need to verify this).

Joe
Guillaume Nodet wrote:
I've gone ahead and change back to the previous state.
I've made one change though which is to have the bundle export and
import the javax.transaction.* packages.
This should allow both ways to work, i.e.
   * have your system bundle exporting the javax.transaction package
with version 1.1 and have jta api in the system classpath
   * boot delegate javax.transaction.* package and add a mandatory
attribute on those pacakges exported by the jre

On Fri, Mar 5, 2010 at 00:48, Guillaume Nodet <gno...@gmail.com> wrote:
Why did you change that behavior ?
Did you set up your environment to boot delegate and add the mandatory
attribute on the transaction packages on your system bundle ?
This is the way it is supposed to work.
See the follwoing config file for example:
  
http://svn.apache.org/repos/asf/felix/trunk/karaf/assembly/src/main/filtered-resources/etc/config.properties

On Fri, Mar 5, 2010 at 00:12, Brian De Pradine <prad...@uk.ibm.com> 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 <joeb...@gmail.com> 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








--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com






--
Joe