[jboss-as7-dev] How to access a AS7 service from a deployed archive?

Jeff Mesnil jmesnil at redhat.com
Fri Sep 21 05:46:09 EDT 2012


On 09/20/2012 06:39 PM, Jason Greene wrote:
>
> There really is no portable way to get at TransactionManager. However you should be able to do it from a rar using a jndi lookup on java:/TransactionManager or java:jboss/TransactionManager. IIRC the service dependency isn't a strict requirement at that stage.
>
> Otherwise to get at the ServiceContainer you should be able to use a ServiceActivator in the RAR (requires a META-INF/services/* entry).

I have a patch where I use JNDI to get the TransactionManager.
But HornetQ RA also support auto recovery that needs access to the Tx's RecoveryManager that is not exposed through JNDI.
I was looking for a general solution for this. Using a ServiceActivator might be it. Not supporting AS7-specific features from a 
deployed RA is another option.

> BTW whats the main use case of this? The ability to use a different version of a hornetq client?

No, the use case is to be able to use the RA to consume messages from a remote JMS server. It should not be necessary to start a 
local HornetQ server for that.
Note that the RA works fine as it is except for 2 edge cases (*autorecovery* and *tx timeout* that requires access transaction 
subsystem's services). The question is: when we deploy HornetQ RA in a standalone AS7, do we want to support these 2 features or 
not? These 2 features will not be supported when the RA is deployed on other app servers in any case.

> Looking at the forums links it seems we need to fix a few things in our subsystem configuration. Is there a way we could not require a running server to configure the pooled connection factory?

I think you are right, that's the cleanest solution.
Actually, the pooled connection factory should *not* have been put inside the hornetq server, they are able to work without one 
(it's similar to the JMS bridge with that respect).

However, this is a lot of configuration/code changes for small benefits (tx timeout or auto recovery) that can be work around 
having a local hornetq-server running (without any acceptors defined and open sockets, it is harmless).

I am not convinced it is worth it. I'm much more of in favor to not change anything (i'm lazy :) and keep things simple:

* if the RA is deployed as a standard RA => no AS7-specific features (e.g. auto recovery)
* if the RA is used through the messaging subsystem => AS7 features are supported out of the box

> On Sep 20, 2012, at 11:09 AM, Brian Stansberry <brian.stansberry at redhat.com> wrote:
>
>> I'm pretty much a noob when it comes to this RA, but this sounds
>> architecturally odd to me.

It is odd. the JCA spec does not define a way to get a reference to the TransactionManager from a RA for a good reason. It does 
not make sense for a XAResource to require a ref to its TransactionManager.
HornetQ RA wants to do this to support a legacy feature (set the tx timeout on the MBD activation spec). Our TM implementation 
overrides the XAResource tx timeout with its own. The only way to let the MDB set a tx timeout is to set it on the TM.

jeff

-- 
Jeff Mesnil
JBoss, a division of Red Hat
http://jmesnil.net/


More information about the jboss-as7-dev mailing list