anonymous wrote :
| For instance, JBM has a messaging bridge - which can run standalone in basically a
stripped down version of JBoss. The bridge creates connections to other jms servers, and
(depending on QoS required) consumes and send messages from one server to the other in a
JTA transaction.
|
How stripped down? I would be interested to see how you got rid of JCA being that, without
it, JBoss typically won't run (at least all those parts of the code requiring JDBC
access). I am assuming that your JMS implementation is using a persistence store is it
not? Are you managing your connections yourself, do you rely on JBoss to do this? If the
latter..well...I hate to be the bearer of bad tidings... ;-)
anonymous wrote :
| So, yes, I admit that from inside the JEE app server, all XA stuff should be done via
JCA, but should we limit ourselves to that?
|
On the 'Design of JCA on JBoss' forum we will.
anonymous wrote :
|
| Why not abstract out the recovery stuff to another service which can be used by both
JCA and anyone else?
|
Because this is what the SPI contract of JCA already provides to a ResourceAdapter,
ResourceManager, Application Server and Transaction Manager. Again, this is in the context
of JBoss 4.2 and what needs to be done to finish this work. Not JBoss5 or later. If you
want, please feel free to start another thread to that end.
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4006054#...
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...