Customer has highlighted a security issue using an MDB example.

From the case:
----------------------------------------------------------------
Could someone from SBR Messaging take Kevin's example to the Messaging dev team, to see how it can be resolved?

Some background information from the corresponding email thread:

--------- Justin: ------------------
> I just went through the attached zip and I'm confused by a few
> things:
>
> 1) The MDB is making direct use of the transaction manager which a
> no-no according to the JTA spec. The transaction manager is not
> to be used by applications.
> 2) The MDB is creating its own XA JMS connection using
> "XAConnectionFactory" rather than letting the container do it
> automatically using "JmsXA".
>
> Once I changed the MDB to use the recommended configuration
> everything worked fine. The new MDB is attached. Of course, I
> changed the credentials that are injected into JmsXA like so:
>
> <application-policy name="JmsXARealm">
> <authentication>
> <login-module
> code="org.jboss.resource.security.ConfiguredIdentityLoginModule"
> flag="required">
> <module-option name="principal">guest</module-option> <!--
> not used by JMS -->
> <module-option name="userName">user2</module-option>
> <module-option name="password">user2</module-option>
> <module-option
> name="managedConnectionFactoryName">jboss.jca:service=TxCM,name=JmsXA</module-option>
> </login-module>
> </authentication>
> </application-policy>
>
> Is there a reason the customer cannot use a configuration like this?
> The code is much simpler, should be more performant, and is more
> easily configured.
>
>
> Justin

-------- Kevin: ----------------------

> > 1) The MDB is making direct use of the transaction manager which
> > a
> > no-no according to the JTA spec. The transaction manager is not
> > to be used by applications.

Unfortunately this is irrelevant to the issue, the MDB code is just reflecting the internal ESB codebase. It is not intended to highlight a 'correct' MDB application but rather the JBM bug being exposed through the ESB usage. Our pool manages the enlistment of the resources in a similar way to JCA, based on the JMS client APIs.

> > 2) The MDB is creating its own XA JMS connection using
> > "XAConnectionFactory" rather than letting the container do it
> > automatically using "JmsXA".

Unfortunately this is not possible as we deal with the JMS client classes, rather than the JCA based wrappers, so that we can handle the pooling outside of the application server as well as within.

Kev