Specifying the MQ username for connecting to a remote queue

Long before your time, there was a WebSphere 7 function, for using JMS to talk to Message Queues. The connectivity made use of (we believe) a default "mqm" username for accessing messages. Both the application server and codes have no awareness of such an arrangement. Nobody had any idea about this, until we were forced to dig deep into this discrepancy.

Then along came WebSphere 9, which turns out was slightly more advanced. The default is no longer used. Instead, it uses the service account that the application server was running on. This introduced some problems. The same identity needs to exist on the remote queue server that the WAS9 is connecting to. 

For most people, this might have easily concluded by having the same account be created on the other side. Naturally, this was not what is happening to warrant this post. In light of some revelations, a username that is different from the one already running the WAS9 was to be used.

I found out that it was risky to try setting the clientID, with due consideration for resource contention in a clustered environment. We tried poking around the J2C authentication alias, but it seemed to require a lot more configuration. The other option, was the username, as suggested by IBM documentation.

In order to set the value in, I located this UserCredentialsConnectionFactoryAdapter for Spring. As suggested here as well, 

For example, when using Basic client authentication, the username and password set for the Initial Context and used for the JNDI connection are inherited from the JMS data connection. However, these properties can be overridden by a username and password provided in the Connection Factory.

 I'd followed the example approximately:

 <bean id="myTargetConnectionFactory" class="org.springframework.jndi.JndiObjectFactoryBean">
   <property name="jndiName" value="java:comp/env/jms/mycf"/>
 </bean>

 <bean id="myConnectionFactory" class="org.springframework.jms.connection.UserCredentialsConnectionFactoryAdapter">
   <property name="targetConnectionFactory" ref="myTargetConnectionFactory"/>
   <property name="username" value="myusername"/>
   <property name="password" value="mypassword"/>
 </bean>

We fiddled a bit with it and took it for a spin. It seemed to take, so we were quite relieved that we didn't have to spend another 2 weeks rewriting a bunch of codes for a fix. At this point, we can confirm that the JMSXUserID remains as "mqm", according to our debug logs.

This had been a very obscure lesson, with nary an article that detailed what needed to be done. Our work is yet to done (will it ever?) but this was quite the wild ride that my colleagues and I took.