Currently on our Tomcat configuration with JNDI is based on this recommendation which currently is working.
How do I connect to a Websphere MQ (MQ Series) server using JMS and JNDI?
Since we are upgrading to v8 I would like to take advantage of the JMS 2.0 features. This would require updating the jar files to the JMS 2.0 versions.
So I have removed the following jars from the tomcat lib folder.
- com.ibm.mq.jar
- com.ibm.mqjms.jar
- connector.jar
- dhbcore.jar
- geronimo-j2ee-management_1.0_spec-1.0.jar
- geronimo-jms_1.1_spec-1.0.jar
And replaced them with these jars. Base on this link
- com.ibm.mq.allclient.jar
- com.ibm.mq.traceControl.jar
My JNDI configuration matches this configuration.
<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="<mymqserver>"
PORT="1414"
CHAN="<mychannel>"
TRAN="1"
QMGR="<myqueuemanager>"/>
Now with the updated jar files I'm getting the following exceptions.
Caused by: java.lang.NoClassDefFoundError: javax/jms/JMSRuntimeException
at com.ibm.mq.jms.MQQueueConnectionFactoryFactory.getObjectInstance(MQQueueConnectionFactoryFactory.java:69)
at org.apache.naming.factory.ResourceFactory.getObjectInstance(ResourceFactory.java:141)
at javax.naming.spi.NamingManager.getObjectInstance(NamingManager.java:321)
at org.apache.naming.NamingContext.lookup(NamingContext.java:842)
at org.apache.naming.NamingContext.lookup(NamingContext.java:153)
at org.apache.naming.NamingContextBindingsEnumeration.nextElementInternal(NamingContextBindingsEnumeration.java:117)
at org.apache.naming.NamingContextBindingsEnumeration.next(NamingContextBindingsEnumeration.java:71)
at org.apache.naming.NamingContextBindingsEnumeration.next(NamingContextBindingsEnumeration.java:34)
at org.apache.catalina.mbeans.GlobalResourcesLifecycleListener.createMBeans(GlobalResourcesLifecycleListener.java:138)
at org.apache.catalina.mbeans.GlobalResourcesLifecycleListener.createMBeans(GlobalResourcesLifecycleListener.java:110)
at org.apache.catalina.mbeans.GlobalResourcesLifecycleListener.lifecycleEvent(GlobalResourcesLifecycleListener.java:82)
at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:117)
at org.apache.catalina.util.LifecycleBase.fireLifecycleEvent(LifecycleBase.java:90)
at org.apache.catalina.util.LifecycleBase.setStateInternal(LifecycleBase.java:402)
at org.apache.catalina.util.LifecycleBase.setState(LifecycleBase.java:347)
at org.apache.catalina.core.StandardServer.startInternal(StandardServer.java:724)
at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150)
... 7 more
Questions:
Should I be including another jar file to the class path?
Or has the configuration of JNDI changed for v8?
Please do NOT try adding the JMS Jar found in the MQ installation. IBM has as of v8.0 repackaged JMS so that a stand-alone install of the jar files is now supported. But only if you use the complete and intact set of jars and do not mix and match them on a whim. To do so would be reckless and ill-advised.
You are on the right track but for your purposes I would go grab the file from the latest 8.0.0.x MQ Client Fix Pack. I would then go to the Technote that explains the install procedure and try that.
I'm sure that IBM has a process for grabbing jars from the server install, however since these appear to be packaged differently, I'd put my money on the package designed and tested for stand-alone delivery - e.g. the one I linked to above.
By the way, since this is now supported if it doesn't work you can open a PMR, tell IBM you followed their instructions to the letter, and make them walk through fixing it with you. (Then post here what it was that fixed it.) But they won't do that if you just go grabbing random jar files and hope it works.