Environment:
Tomcat 6.0.10
WindowsXP
Websphere MQ6.0 as the JMS provider
I've having mixed success using axis2 with Websphere 6 as my JMS transport.
My serverXMl contains the following entry:
<Resource
name="jms/MyQCF"
auth="Container"
type="com.ibm.mq.jms.MQQueueConnectionFactory"
factory="com.ibm.mq.jms.MQQueueConnectionFactoryFactory"
description="JMS Queue Connection Factory for sending messages"
HOST="10.20.240.112"
PORT="1414"
CHAN="CLIENTS"
TRAN="1"
QMGR="GRM"/>
<Resource
name="jms/MyQIn"
auth="Container"
type="com.ibm.mq.jms.MQQueue"
factory="com.ibm.mq.jms.MQQueueFactory"
description="JMS Queue for receiving messages"
QU="Q.IN"/>
I setup the axis2.xml conf file appropriately and *everything works*. Messages
in and out. :-)
The problem starts when I try to use a QueueManager on another machine remote
from Tomcat. I get a security error.
Now I see in that in the JMSConnectionFactory.java file we have two calls to
create a connect thus:
con = conFactory.createConnection();
There is another JMS method of creating a connection (which we don't use - yet):
con = conFactory.createConnection(userID, password);
For any non-WebsphereMQ people here, there are twoways of connectiing to a
Websphere QueueManager / QueueConnectionFactory:
1. Server/Bindings - local connection on the same machine, OS credentials are
used
2. Client - remote connection to a queuemanager - ****userID and Password must
be supplied.****
My example above is calling using the 'CLIENT' method. So as I have no-where to
supply the userID and password, my connection attempt fails.
So can anyone either:
1. Advise how I should be performing userID/password credentials for
WebsphereMQ CLIENT connections using the current structure. (perhaps with
java.naming.security.principal / java.naming.security.credentials)
or
2. Do you think that I should generate a patch to allow use to use either type
of connection method?
con = conFactory.createConnection();
con = conFactory.createConnection(userID, password);
(I'm also asking this question in a specialist MQ forum for further insight)
Cheers,
Mark B