related to https://jira.jboss.org/jira/browse/JBMESSAGING-1506
currently, the MessagingXAResourceRecovery depends on JMS and JNDI to retrieve the JMS XASession used to recover.
The information is passed as a String in jbossts-properties.xml:
<property name="com.arjuna.ats.jta.recovery.XAResourceRecovery.JBMESSAGING1" value="org.jboss.messaging.jms.server.recovery.MessagingXAResourceRecovery;$jndi,$user,$password" />
where $jndi is the JNDI lookup for the XAConnectionFactory and $user and $pass are the (optional) user credentials.
We can get rid of the dependencies to JMS and JNDI as JBoss Messaging Core API exposes its ClientSession as a XAResource directly.
In order to use a ClientSession we need to create a ClientSessionFactory from inside the MessagingXAResourceRecovery.
The only constraint is that the single input we have to this class is the String passed to its initialise() method.
There are 2 possibilites:
1. Pass all the informations required to create the ClientSessionFactory under a serialized form directly in the String
2. Put all the information in a configuration file and pass the file configuration name to the MessagingXAResourceRecovery and read the content from there
#1 is simpler. If we constraint to only support a connection to a single live server, the initialization string would be:
"$connectorFactoryClassName, $user, $pass, key1=val1, key2=val2"
This would be enough to create a TransportConfiguration with the class name and the parameters.
Then we could create a ClientSessionFactory and a ClientSession (with the optional user credentials)
However this limits the type of connection supported by the recovery to a single server.
Does it make sense for JBM 2 to have the TM recover from something else than the Messaging Server embedded in the same server instance than the TM?
If that's the case, we could put the client session factory in a separate configuration file (with the support of whole stuff, discovery, live and backup servers, etc.) and read this config file from the MessagingXAResource.
The cons is that it means yet another configuration file and it may be too complex for 80% (99%?) of the case where the TM will recover the messaging resources from the same server.