"jndiParameters" activation configuration property

[Ahmed Theba]

Hi,

First up, thanks all round to the team who made the RA possible. 

I was wondering however if it would be possible to use the parameters specified in the resource adapter outgoing configuration instead of being required to specify activation config properties. i.e. make the activation config properties for jndi, username & password optional and if not specified on the mdb then use the parameters from the RA specified in the standalone-full.xml configuration?

I am working with a large development team and code-base. We already have a large number of MDBs and a custom RA. We also keep the configuration for Dev, QA & Prod accessible to only those with permissions to view/edit these. In order to keep the transition seamless, it would be helpful to be able to use the properties from the resource adapter.

Looking through the code it appears if the JmsMCFProperties could be exposed by JmsManagedConnectionFactory and then if JmsActivation uses these properties instead of the properties from the JmsActivationSpec, that this would be possible?

Regards,

Ahmed

[Justin Bertram]

I believe your idea is theoretically possibly.  However, since there is only one activation specification per MDB and there can be multiple outbound connection factories there would need to be some way to tie the two together.  Feel free to try implementing this.  The RA is open source after all.

That said, there is already a way for an MDB to share its configuration properties with an outbound connection factory using system properties (at least in Wildfly).  I've mentioned this option in the past, but I only mentioned using a deployment descriptor (e.g. ejb-jar.xml).  However, you can also specify system properties in annotations themselves.  You can define system properties in your server configuration file and then use those properties in both your MDB(s) and outbound connection factories.

Lastly, I don't understand why you're using this RA when, as you say, you already are using "a custom RA".  Can you elaborate on this point?

[Ahmed Theba]

Hi Justin,

You called it... 

"However, since there is only one activation specification per MDB and there can be multiple outbound connection factories there would need to be some way to tie the two together."

I have written some code and realized this when testing. The resource adapter id uniquely identifies the outbound factory however the id is not available within the MCF properties. 

We are currently using EAP 6.3.2 and the system properties mechanism should work. However this would require changes to a lot of MDBs within the codebase. It definitely is a viable option. 

The custom RA we are using is a result of legacy code that worked with weblogic and was inherited when we moved over to JBoss. The RA works, however it is a bit clunky. We have a home brewed library that reads out the connection factory information from the DB and then creates these factories by using the tibjms library. These instances are provided with a local jboss jndi name reference. All of this happens on server startup with a singleton EJB. The MDBs have generic-jms-ra specified as the resource adapter with minimal configuration in standalone-full.xml in order to bypass the hornetQ factory. The generic-jms-ra configuration has java.naming.factory.url.pkgs=org.jboss.ejb.client.naming specified for the JndiParameters property. The MDBs use the local jndi names for the connection factory and queue references.

What I am hoping to gain is a less convoluted setup and more control over the factories themselves i.e. pooling, enabled etc.

Regards,

Ahmed

[Justin Bertram]

I gave this a little thought...

If I were going to implement this myself I would probably use the existing "connectionFactory" activation configuration property and point it to a local connection factory and if that connection factory was an instance of org.jboss.resource.adapter.jms.JmsManagedConnectionFactory then I would call getProperties() on it to get its org.jboss.resource.adapter.jms.JmsMCFProperties and then use the properties from that to override what was set on the MDB's activation specification configuration.

[Ahmed Theba]

Hi Justin,

That's exactly what I did on my side now. I created my own class which extends JmsManagedConnectionFactory and has a static map<String, JmsMCFProperties>.

The connectionFactory specified on the MDB as an activation config property is the key to this map. 

The JmsMCFProperties retrieved from the map are then used for:

1. jndi parameters

2. username

3. password

This looks like it should work, however I will test for the case with more than one resource-adapter configuration specified in the standalone-full.xml.

[Ahmed Theba]

Justin,

I just realized that the aforementioned will create an issue in that our organisation has multiple Tibco server(s) and connection factories which are used depending on which sub-company is being communicated with. The issue is that although the servers/factories are different the connection factory name is the same on all these servers.

I think adding a new parameter to the MCF properties and specifying this in the ra.xml would solve this issue. I would then use the local jndi name of the factory for this parameter and likewise for the connection factory activation config property specified on the MDB.

Not as elegant a solution as this would require the local connection factory name being specified twice in the RA configuration within standalone-full.xml. But necessary in our situation.

Regards,

Ahmed Theba

[Justin Bertram]

One quick note...

Keep in mind that as your modification becomes more and more specific to your particular use-case the less and less likely it is to be accepted if you wish to commit it back to this project.  You're certainly free to fork this project and create your own for your particular use-case, but of course that means you'll be responsible for maintaining your fork, fixing bugs if you hit them, and applying fixes made to the main project (if you want).

[Ahmed Theba]

Hi Justin,

Yes I realize this... I think this addition would be useful to the community and I would gladly commit back to the project.

I am currently getting a Tibco connection factory inventory from each of our sub-companies to compare.

We might have the following situation:

<connection-definition class-name="org.jboss.resource.adapter.jms.DiscLifeJmsManagedConnectionFactory" jndi-name="java:/jms/TibcoJMSXA1" enabled="true" use-java-context="true" pool-name="TibcoJMSXA" use-ccm="true">

<config-property name="JndiParameters">

java.naming.factory.initial=com.tibco.tibjms.naming.TibjmsInitialContextFactory;java.naming.factory.url.pkgs=com.tibco.tibjms.naming;java.naming.provider.url=tibjmsnaming://tibco01:7222;

</config-property>

<config-property name="UserName">

username

</config-property>

<config-property name="Password">

password

</config-property>

<config-property name="ConnectionFactory">

TibConnectionFactory

</config-property>

<security>

<application/>

</security>

</connection-definition>

<connection-definition class-name="org.jboss.resource.adapter.jms.DiscLifeJmsManagedConnectionFactory" jndi-name="java:/jms/TibcoJMSXA2" enabled="true" use-java-context="true" pool-name="TibcoJMSXA" use-ccm="true">

<config-property name="JndiParameters">

java.naming.factory.initial=com.tibco.tibjms.naming.TibjmsInitialContextFactory;java.naming.factory.url.pkgs=com.tibco.tibjms.naming;java.naming.provider.url=tibjmsnaming://tibco02:7222;

</config-property>

<config-property name="UserName">

username

</config-property>

<config-property name="Password">

password

</config-property>

<config-property name="ConnectionFactory">

TibConnectionFactory

</config-property>

<security>

<application/>

</security>

</connection-definition>