DevGrok

Standalone tracing WebSphere MQ classes for JMS applications It’s a relatively simple process to enable logging for MQ JMS client libraries. 1. Add a reference WebSphere MQ classes for JMS configuration file . Here is the command line arguments to reference the common services properties files called “mqjms.properties” for MQ. Note: the location for the MQ classes for JMS is a uri (i.e. prefix it with file:) whilst the location for MQ classes for Java is a regular path and annoyingly it won’t give you an error if it can’t correctly read the file. Also included is a reference to a java keystore and turning on java.net logging for SSL and connection handshaking as getting MQ and SSL working seems to be a constant battle, with cipher suites being the most common cause. I even had trouble trying to use the same ssl/cipher from WLP in both standalone JMS and in the non-JMS setup. It seems to require some trial and error for each of the 3 ways of using MQ listed here. -Dcom.ibm.msg.cli...

When loading an application in an osgi-like container with an app that references jabx-impl, you might see the following warning: [WARNING ] SRVE9967W: The manifest class path jaxb-api.jar can not be found in jar file file:/D:/Java/maven/repo/com/sun/xml/bind/jaxb-impl/2.2.7/jaxb-impl-2.2.7.jar or its parent. [WARNING ] SRVE9967W: The manifest class path jaxb-core.jar can not be found in jar file file:/D:/Java/maven/repo/com/sun/xml/bind/jaxb-impl/2.2.7/jaxb-core.jar.jar or its parent. This one is caused by the specific reference to jaxb-api.jar and jaxb-core.jar in jaxb-impl-2.2.7.jar/META-INF/MANIFEST.MF: Class-Path: jaxb-api.jar jaxb-core.jar The artifacts that maven pull in have a different filename (with a version number) that doesn't match the expected build version. e.g. jaxb-core-2.2.7.jar and jaxb-api-2.2.7.jar The solution: Create 2 empty zip files and name them jaxb-core.jar and jaxb-api.jar Place them into proj/src/main/WEB-INF/lib Done

Setting the necessary properties on the Java Client for MQ libraries in order to pass the ApplIdentityData is quiet simple, as mentioned in this stackoverflow post : MQDestination queue; //... queue.setBooleanProperty(WMQConstants.WMQ_MQMD_WRITE_ENABLED, true); queue.setBooleanProperty(WMQConstants.WMQ_MQMD_READ_ENABLED, true); queue.setIntProperty(WMQConstants.WMQ_MQMD_MESSAGE_CONTEXT, WMQConstants.WMQ_MDCTX_SET_ALL_CONTEXT); javax.jms.Message message; //... message.setStringProperty(JmsConstants.JMS_IBM_MQMD_APPLIDENTITYDATA, "...."); The meaning of the properties is listed in the documentation: Destination object properties . If using Websphere Application Server, you can define a Jms Queue as a Resource which can be intern looked up via JNDI. IBM has a pretty good summary of the different methods. How to read and write fields from the MQMD via WebSphere MQ Classes for JMS Version 7: direct, using JNDI and using WebSphere Application Server . To set it up in WAS7 f...