"weston.price(a)jboss.com" wrote : I may have initially underestimated this task.
The JcaXAResourceWrapper, by itself, is not sufficient for recovery integration. I have
started on
|
|
| | org.jboss.resource.connectionmanager.xa.JcaXAResourceRecovery
| |
|
| for this purpose. It's easy enough to configure something like this for
DataSources such as
|
|
| | <property
name="com.arjuna.ats.jta.recovery.XAResourceRecoveryJCA=org.jboss.resource.connectionmanager.xa.JcaXAResourceRecovery;DSNAME1,
DSNAM2"/>
| |
|
| the issue I am not following is for DataSource and other JCA deployments that rely on
a CRI, Subject etc. I would assume that for recovery purposes, a default connection of
some sort will have to be provided by the client to allow JBossTS to do it's job. This
would seem to suggest that we are now at the very least going to force a separate
deployment for recovery if the default deployment cannot be accessed in this manner. The
JMS example assumes the creation of a connection without JMS credentials so I am assuming
I am in the same boat.
|
| I can't see any other way to do this unless we made them provide a separate
configuration file for their resources that we could access that would allow me to
recreate the underlying resource.
|
|
When I wrote the ResourceRecovery instance for the JMS bridge, it gets its config from a
properties file, which also (optionally) contains the username and password to create the
XAConnection to get the XASession and XAResource.
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4009329#...
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...