Question

I have read the article http://techtots.blogspot.com/2010/01/connecting-to-mq-using-spring-without.html about configuring QueueConnectionFactories and have that side of things working nicely.

# MQ related values
mq.jms.qcf=QM_Epsilon
mq.jms.request.queue=TEST.REQUEST.QUEUE

# Connection details
mq.host.url=localhost:1414/SYSTEM.DEF.SVRCONN
mq.factoryclass=com.ibm.mq.jms.context.WMQInitialContextFactory

# Authentication details
mq.auth=simple
mq.user=******
mq.password=********

---

<bean id="queueConnectionFactory" class="org.springframework.jndi.JndiObjectFactoryBean">
    <property name="jndiName" value="${mq.jms.qcf}" />
    <property name="resourceRef" value="false" />
    <property name="jndiEnvironment">
        <props>
            <prop key="java.naming.factory.initial">${mq.factoryclass}</prop>
            <prop key="java.naming.provider.url">${mq.host.url}</prop>
            <prop key="java.naming.security.authentication">${mq.auth}</prop>
            <prop key="java.naming.security.principal">${mq.user}</prop>
            <prop key="java.naming.security.credentials">${mq.password}</prop>
        </props>
    </property>
</bean>

Using this configuration the queueConnectionFactory bean is easily injected into my classes as an MQQueueConnectionFactory.

But I am wanting to use the publish/subscribe model and, as I understand it, I need to get an MQTopicConnectionFactory for this. I have searched everywhere and tried numerous things but I cannot find any information on how to modify this configuration, or the MQ installation so that I get an MQTopicConnectionFactory instead of an MQQueueConnectionFactory.

Answer 1

The WMQInitialContextFactory is a class that implements a JNDI provider over a WebSphere MQ queue. Instead of the managed objects being stored in a .bindings file or LDAP, they are serialized and stored in a queue and this class allows you to treat that queue as just another JNDI store. This class was only ever intended to be a JNDI provider and not a replacement for the actual IBM JMS implementation. Since storing managed objects on a topic would not work, these classes have no topic factories in them. This is as expected.

In my opinion, the problem with WMQInitialContextFactory is that it must first connect to WebSphere MQ in order to to obtain a connection factory which then tells the app – you guessed it – how to connect to WebSphere MQ. This makes the article that was linked confusing because it appears that all that configuration, the WMQ connection details and so forth, are for the benefit of the application when in fact they just bootstrap a JNDI provider which is expected to have defined connection factory objects with all this same information.

What is missing from the article is that the author would have had to use IBM’s JMSAdmin tool to connect to the MQInitialContext and define the ConnectionFactory and other administered objects before connecting the application to that same Initial Context in order to access them.

For the record, the WebSphere MQ JMS classes have supported JMS 1.1 ConnectionFactory and Destination classes for quite some time now. Prior to that they supported both queues and topics as per the JMS 1.0 spec.

You can download the IBM WMQ JMS implementation as SupportPac MQC7. There is a lot more there than just the jar files. For example, you get lots of sample code, diagnostic and trace utilities, documentation, etc. You also get the correct jar files.

If you want to use a .bindings file (File-system initial context) instead of the WMQInitialContextFactory, download the latest WebSphere MQ Explorer tool as SupportPac MS0T. You can create a directory, point WMQ Explorer to it and define all your connection factories and destinations. (Or go with domain-specific QueueConnectionFactory and TopicConnectionFactory if you rock it old school.) More information on using WMQ Explorer to define your managed objects may be found at: Creating and configuring JMS administered objects

If you want a tutorial that includes a demonstration of how to use IBM’s JMSAdmin tool to create the .bindings file, look at Running a standalone Java application on WebSphere MQ V6.0. (The JMSAdmin tool is installed with the WMQ Server and I believe it also comes with the free MS0T WMQ Client install linked above.) The documentation for the JMSAdmin tool is here: Using the WebSphere MQ JMS administration tool

Whichever method you choose to create managed objects, you can look up all the possible properties supported in IBM’s implementation at: Properties of WebSphere MQ classes for JMS objects