[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