I am trying to create a JMS connection from WebSphere App Server 7, but keep getting JMSWMQ2013 (with MQ reason code 2035). Clearly this is an authentication problem, and I can see many other similar reports so I have a rough idea of the general problem.
I'm awaiting feedback from our operations team as to the exact configuration of the channel, however, in the meantime I have one observation that is quite puzzling. If I use WebSphere's JAAS authentication to provide the userid, then I always get the JMSWMQ2013
error. , however, if explicitly pass the same userid to the JMS queue connection factory's call to createQueueConnection()
, then I don't get the authentication error.
To be honest, I would have expected both techniques to behave consistently. Is there some subtlety that I am missing with using JAAS to provide the credentials for a JMS queue connection factory?
Edit: I turned on JMS tracing in WAS using *=info: JMSApi=all: JMSServer=all: Messaging=all: JMS_WASTraceAdapter=all: com.ibm.mq.*=all: jmsApi=all
, and compared the output line by line.
When using JAAS I can can see that deep in the bowels of JmsXAQueueConnectionImpl
it is actually calling WMQConnection.getProcessUserId()
which returns the userid that my WAS instance is running under (which is definitely not the user that is defined in the channel's MCAUSER
).
It is all quite odd... it doesn't seem to be picking up the JAAS authentication entry at all. My QCF definitely is using CLIENT transport with a mapping configuration alias of DefaultPrincipalMapping, but for some reason it is still using the process's userid instead of the JAAS userid.
Thanks. Craig