log4j: java.lang.ClassCastException: com.ibm.ejs.jms.JMSTopicConnectionFactoryHandle incompatible with javax.jms.TopicConnectionFactory on WebSphere 9

Question

I'm having some struggles getting a Java web-application running on IBM WebSphere Application Server 9.0.5.5 sending messages to an IBM MQ topic using log4j 1.2.17.

In WAS we originally had a ConnectionFactory set up to use to communicate with the topic. This is what we do with other applications that use IBM MQ queues. However, this ends up giving me the following error:

java.lang.ClassCastException: com.ibm.ejs.jms.JMSConnectionFactoryHandle incompatible with javax.jms.TopicConnectionFactory

I found an IBM article that discusses a similar issue with queues and the solution is to use a QueueConnectionFactory. So, similarly I switched from using a ConnectionFactory to a TopicConnectionFactory. Now I get this error:

java.lang.ClassCastException: com.ibm.ejs.jms.JMSTopicConnectionFactoryHandle incompatible with javax.jms.TopicConnectionFactory

I have another Java web-application that uses log4j2 with queues. We have a ConnectionFactory set up in WAS in Resources > JMS as we did here with this application. It all works fine. The only difference here is that we are using log4j 1.2.17 and topics instead of queues.

I cannot change the version of log4j because it is baked into the vendor platform we have.

I checked the WAR file that is being deployed and there is only the one jms.jar (and fscontext, providerutil, mq, etc. JARs for IBM MQ Client 9.1.0.0) in there. So no other competing jms.jar that might be of an older JMS version.

Any ideas what could be wrong here?

Answer 1

This took A LOT of back and forth with IBM to get it to work. I'd have to go through the case history, but for now I can just share what I see in our JMS configuration in WAS.

• In each environment, we are running with 2 WAS nodes.
• On each WAS node, we created a Topic connection factory with scope at the Node level.
• In the factory, we have both of our MQ servers for that environment listed in our Connection name list
• We also set up a JAAS - J2C authentication resource as a user id is required to access our MQ servers.
• We also created a Topic object at the Node scope level.

That's basically it. Now, we did have a lot of issues on the MQ side with permissions not being set up properly that IBM was able to identify in some traces we sent.

I'd say if you are still stuck, open a case with IBM. It took a little while to get to the right resources, but after running some traces they were able to find our issues.

Good luck @rajib-biswas!