CHANGQING YE's WEBLOG

Have you seen the following exception when you run your application in Websphere application server?

“CWSIA0114E: The property JMS_IBM_MsgType should be set
using type java.lang.Integer, not java.lang.String.”

I do have such a problem. Why?

As we know JMS messages are composed of three pars on the JMS specification:
- Header
- Properties
- Body
Among them, Properties include Application-specific properties,Standard properties and Provider-specific properties.

Websphere MQ messages are composed of three parts:
- MQ Message Descriptor (MQMD)
- MQ MQRFH2 Header
- Body

From JMS message to MQ message or from MQ message to JMS message, the transformation is required. The transformation model is defined below:

The transformation is done in two approaches:

Mapping – where the MQMD includes a field that is equivalent to the JMS field, the JMS field is mapped onto the MQMD field. Additional MQMD fields are exposed as JMS properties, as a JMS application may need to get or set these fields when communicating with a non-JMS application.

Copying – where there is no MQMD equivalent, a JMS header field or property is passed, possibly transformed, as a field inside the MQRFH2.

In this case, mapping is not correct. The MQ specific property JMS_IBM_MsgType is integer type and has to be set as
JMSMessage.setIntProperty(“ JMS_IBM_MsgType”,some-valid-value)

In a message pass through use case, we need to copy inbound message properties to outbound message properties, we can check if inbound message is websphere message type using following approach:

if(inboundJMSMessage.getClass().getName().startsWith(" com.ibm.jms.JMS") ||
inboundMessage.getClass().getName().startsWith(" com.ibm.ws.sib.api.jms.impl.Jms"))

{
// do mapping and copying
}

More about Mapping JMS messages onto WebSphere MQ messages, refer to
http://www-306.ibm.com/software/integration/mqfamily/library/manualsa/csqzaw04/csqzaw2r.htm
http://publib.boulder.ibm.com/infocenter/wmqv6/v6r0/index.jsp?topic=/com.ibm.mq.csqzaw.doc/csqzaw1481.htm

 

Java CAPS supports JDK 1.5. To run Java CAPS on JDK 1.6, we need to manually change the packaged JRE 1.5. Java CAPS includes several components which run on their own JRE environments. We take Logical-Host as a example. You can do as follows:

• Install logicalhost somewhere, for instance, C:\JavaCAPS\logicalhost

• Create domain1

• Rename C:\JavaCAPS\logicalhost\jre to C:\JavaCAPS\logicalhost\jre.old

• Download JDK 1.6 and install somewhere, for instance, C:\java

• Copy C:\java\jdk1.6.0\jre to C:\JavaCAPS\logicalhost\jre

• Copy C:\java\jdk1.6.0\lib\tools.jar to C:\JavaCAPS\logicalhost\jre\lib

• Copy C:\JavaCAPS\logicalhost\jre\bin\javaw.exe to C:\JavaCAPS\logicalhost\jre\bin\is_domain1.exe

• Copy C:\JavaCAPS\logicalhost\jre\bin\javaw.exe to C:\JavaCAPS\logicalhost\jre\bin\isprocmgr_domain1.exe

• Change C:\JavaCAPS\logicalhost\is\domains\domain1\config\domain1.xml as a workaround:

<!--

<jvm-options>

-Djavax.xml.transform.TransformerFactory=com.sun.org.apache.xalan.internal.xsltc.trax.TransformerFactoryImpl

</jvm-options>

-->

• Start domain1

• Deploy projects into domain1 and projects should run fine.

There are some unsolved issues. For instance, if we do not comment out:

<jvm-options>

-Djavax.xml.transform.TransformerFactory=com.sun.org.apache.xalan.internal.xsltc.trax.TransformerFactoryImpl

</jvm-options>

The following exception will be thrown while the projects created by Java CAPS get deployed:

Caused by: java.lang.NoSuchMethodError: org.w3c.dom.Document.getXmlStandalone()Z at com.sun.org.apache.xalan.internal.xsltc.trax.DOM2TO.setDocumentInfo(DOM2TO.java:373) at com.sun.org.ap|#]

Both JDK 1.5 and JDK 1.6 support DOM Level 3 compliant coding. Why does the project not work with JDK 1.6? These issues will be solved later.