MDB - alternative to spec-descriptor-property-replacement, ejb-jar.xml and system properties?

[Peter]

We are using JBoss EAP 6.1.0.GA to connect with Tibco EMS 5 and Tibco EMS 6.

As far as I can tell, for MDB we need to use:

1. Set spec-descriptor-property-replacement to true from the default of false.

2. Use a ejb-jar.xml file to configure the MDB

3. Use a system property as well.

Within our large organisation with multi-applications, multi-environment and shared hosting, we have these design preferences:

1. Default configuration where possible.

2. Use of annotations rather than ejb-jar.xml files.

3. Avoidance of system properties and isolation of configuration per profile.

4. Server administrators manage usernames and passwords for connections in multiple environments.

Is there a way to use MDB to connect to Tibco EMS that meets our design preferences?

Could the outbound connection factory definition be used for the inbound MDB configuration?

Spring has a concept of different types of DestinationResolver(s) - JndiDestinationResolver and DynamicDestinationResolver

With the JndiDestinationResolver being similiar to the current lookup with .

Perhaps this we could add this concept configuration properties.

i.e.

destinationResolver

- Strategy interface for resolving JMS destinations.

- i.e. DynamicDestinationResolver

- Default JndiDestinationResolver.

- Alternative DynamicDestinationResolver

dynamicDestinationResolverConnectionFactoryJNDIName

- JNDI name of a connection factory used by the DynamicDestinationResolver

- i.e. java:/GenericJms

- Default: null

The DynamicDestinationResolver would use the outbound connection factory to look up the MDB destination.

This approach would allow server administrators to manage both inbound and outbound connections from a single resource adapter configuration and for the MDB annotations to be used.

Any feedback on these questions and idea would be welcome.

[Justin Bertram]

Is there a way to use MDB to connect to Tibco EMS that meets our design preferences?

In short, no.

An outbound connection factory definition cannot be used for inbound.  One is outbound, the other is inbound, and never the twain shall meet.  That's just the way it is with JCA as far as I understand.  Remember, the outbound and inbound connectors don't have to be similar at all from a functional or implementation perspective.  It wouldn't necessarily make sense to use one for the other.

Essentially, you are looking for configuration possibilities that JCA and Java EE simply don't offer

 

[Peter]

We've been looking at various options here.

We have wondered about admin objects, as they have been used in other resource adapters.

The conventional way is to have an admin object define a queue or topic.

But it seems they can contain any object.

So you could use an admin object to define a POJO containing defaults for a MDB.

Examples below.

Fork and branch here: https://github.com/pthiem/generic-jms-ra/tree/JmsActivationSpecDefaultsAdminObject

Any feedback?

Example API:

New MDB Activation Configuration Property:

jndiJmsActivationSpecDefaultsAdminObject - jndi Location for a resource adapter admin object contains default values for an activation specfication. Values from this object will be used if the activation specifications setting for the corresponding value is null. This can be used to set environment specific runtime values for annotation based MDBs.

Configuration for Admin Object (JmsActivationSpecDefaultsAdminObject)

Defines default values that can be used for an activation specification. This can be used to set environment specific runtime values for annotation based MDBs. The MDB must refer to the admin objects jndi location using activation configuration property jndiJmsActivationSpecDefaultsAdminObject.

jndiParameters - the JNDI parameters used to perform the lookup of the destination and the connectionFactory.
user - the name of the user used when connecting to the JMS provider
password - the password used when connecting to the JMS provider

Example Config:

Example Admin Object in Resource Adapter:

                    <admin-objects>

                        <admin-object class-name="org.jboss.resource.adapter.jms.inflow.JmsActivationSpecDefaultsAdminObject" jndi-name="java:jboss/example/jmsActivationSpecDefaultsAdminObject" enabled="true" use-java-context="false" pool-name="jmsActivationSpecDefaultsAdminObject">

                            <config-property name="jndiParameters">

                                java.naming.factory.initial=com.tibco.tibjms.naming.TibjmsInitialContextFactory;java.naming.provider.url=tcp://TIBCO_HOST:7222

                            </config-property>

                        </admin-object>

                    </admin-objects>

 

Example MDB MDB:

 

@MessageDriven( name = "ConsumeMDB", activationConfig = {

                @ActivationConfigProperty(propertyName = "jndiJmsActivationSpecDefaultsAdminObject", propertyValue = "java:jboss/example/jmsActivationSpecDefaultsAdminObject"),

                @ActivationConfigProperty(propertyName = "destinationType", propertyValue = "javax.jms.Queue"),

                @ActivationConfigProperty(propertyName = "destination", propertyValue = "example.queue"),

                @ActivationConfigProperty(propertyName = "connectionFactory", propertyValue = "QueueConnectionFactory"),

})

@ResourceAdapter("generic-jms-ra-<VERSION>.rar" )

@TransactionAttribute(TransactionAttributeType.NOT_SUPPORTED)

public class ConsumeMDB implements MessageListener {

[Justin Bertram]

I'm not crazy about this idea, partially because it appears motivated only by your "design preferences."  There's nothing wrong with design preferences, per se, but in my opinion this is unnecessary complexity to solve a problem that already has a solution.  But more importantly, the idea clashes with the JCA 1.5 specification.  Section 12.4.2.3 states:

Note, administered objects are not used for setting up asynchronous message
deliveries to message endpoints. The ActivationSpec JavaBean is used to hold all
the necessary activation information needed for asynchronous message delivery
setup.

[Ahmed Theba]

We have a similar situation as to the one you posted. A large code-base where it would require a lot of work to implement the generic-jms-ra adapter.

We also need to keep the username/passwords for Dev,QA and Prod separate and administered by a select team.

If I remember correctly the Apache Activemq resource adapter uses admin objects to do exactly as you have mentioned.