Thanks for doing that and my apologies for missing the problem in the
review.
On 5 Mar 2010, at 08:07, 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 <[email protected]>
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 <[email protected]>
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
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
