From IBM MQ 9.1.2 CD onwards, the product started shipping the org.json.jar file as part of the "Java Messaging" component on AIX and Linux, and the "Extended Messaging APIs" feature on Windows. The JAR file contained the classes used by the IBM MQ classes for Java and classes for JMS to parse JSON-format client channel definition tables (CCDTs). This meant that IBM MQ classes for Java and classes for JMS applications that wanted to use JSON-format CCDTs had to include the org.json.jar file on their CLASSPATH. Applications that didn't use a JSON-format CCDT could be run without the new JAR file on the CLASSPATH.
In MQ 9.2.4 CD, the MQ classes for Java and classes for JMS were changed so that calling the toString() method on one of the following objects would return a JSON string containing details of that object:
- com.ibm.mq.MQQueueManager
- com.ibm.mq.jms.MQConnection
- com.ibm.mq.jms.MQSession
The same behaviour was also included in the MQ classes for Jakarta Messaging when support was added for those in MQ 9.3. More information about this can be found in the "What's changed in IBM MQ 9.2.4" topic in the MQ 9.2 documentation.
Here is an example of what a JSON string for a com.ibm.mq.jms.MQConnection object looks like:
{"ConnectionId":"414D51437061756C745639324C545320C3F5296601C98324",
"ObjectId":"com.ibm.msg.client.wmq.internal.WMQConnection@8f5c7651",
"Channel":"MY.SVRCONN",
"Port":"1414",
"ConnectionMode":"WMQ_CM_CLIENT",
"Host":"localhost/127.0.0.1",
"ResolvedQueueManager":"QM1, "QueueManager":"QM1"}
Now, it is fairly common for applications to print out, or log, these types of objects for diagnostic or informational purposes. This means that, from MQ 9.2.4 onwards, applications using the MQ classes for Java, classes for JMS or classes for Jakarta Messaging must have the org.json.jar file shipped with IBM MQ on their CLASSPATH, regardless of whether they are using JSON format CCDTs or not. If they don't, then unexpected behaviour can occur - some examples of this are:
- Applications reporting "java.lang.NoClassDefFoundError: org.json.JSONObject" errors.
- Applications unexpectedly reporting exceptions containing reason code 2009 (MQRC_CONNECTION_BROKEN) when trying to connect to a queue manager.
IBM Support have also heard from one customer who had an application that already had an older version of the org.json.jar file on its CLASSPATH, and the application didn't work properly when the CLASSPATH was changed to use the org.json.jar file included with IBM MQ. This was quite interesting. Ideally, applications should always be using the latest version of the org.json.jar file to keep up to date with bug fixes and security patches (IBM MQ always ships the latest version of the JAR file in its new Fix Packs and Cumulative Security Updates, also known as CSUs). However, there are some cases where applications are tied to behaviour in an older version of the JAR file. In these situations, the application will need to be updated to either support the new behaviour in the latest org.json.jar file, or use multiple classloaders so that the two org.json.jar files (the one shipped with IBM MQ and the version needed by the application) can be loaded into the same Java Virtual Machine.
Oh, and one thing that is worth mentioning is that the org.json.jar file is included in the MQ resource adapter and MQ resource adapter for Jakarta Messaging. This means that it will be available to enterprise applications running inside JEE application servers when either resource adapter is deployed.
As always, I hope this helps! If you have any questions on this, feel free to ask and I'll be happy to answer them.