IV61537: AFTER JRE UPGRADE, NULLPOINTEREXCEPTION THROWN BY APPLICATION WHEN ACCESSING MESSAGE DATA USING WMQ-JAVA CLASSES

APAR status

• Closed as program error.

Error description

• WebSphere Application Server (WAS) v7.0.0.25 using WebSphere
  MQ (WMQ) v7 classes for Java reports a NullPointException while
  sending messages to a WMQ queue manager:
  com.ibm.ws.webcontainer.servlet.ServletWrapper service
  SRVE0068E: Uncaught exception created in one of the service
  methods of the servlet AbcdServlet in application ab_cd.
  Exception created : java.lang.NullPointerException
  

Local fix

Problem summary

• ****************************************************************
  USERS AFFECTED:
  Users of the WebSphere MQ classes for Java v7.0, v7.1,v7.5 and
  v8, when using a IBM JRE at the version:
  
  Java 6.0.0 SR12 and above
  Java 6.0.1 SR4 and above
  Java 7.0.0 SR3 and above
  
  The affected users include users of the WebSphere MQ Resource
  Adapter (WMQ-RA) as used by application servers such as the
  WebSphere Application Server.
  
  
  Platforms affected:
  MultiPlatform, AIX, HP-UX Itanium, HP-UX OpenVMS, HP-UX PA-RISC,
  IBM iSeries, Linux on Power, Linux on S390, Linux on x86, Linux
  on x86-64, Linux on zSeries, Solaris SPARC, Solaris x86-64,
  Windows, z/OS
  
  ****************************************************************
  PROBLEM DESCRIPTION:
  When decoding character data within a message received from
  WebSphere MQ, the WebSphere MQ classes for Java make use of the
  Java class:
  
      java.nio.charset.CharsetDecoder
  
  in order to interpret the bytes within the message to create the
  character data which is provided to the application.
  
  
  Up to the IBM Java 6 SR11, when the CharsetDecoder object
  encountered a unmappable byte sequence, which is a series of
  bytes which cannot be represented in the character set which the
  CharsetDecoder is converting the bytes to, the bytes were
  silently (without any exceptions being thrown) substituted to
  the byte sequence:
  
     0xFF 0xFD
  
  As of the IBM Java APAR IV21353 included in IBM Java 6 SR12, the
  default action for CharsetDecoder changed to report an error for
  unmappable-character, which is seen within trace as an exception
  of the form:
  
  java.io.IOException: MQJE088: Decoding failed
  ('MQMessag2.readConvertedLine():UNMAPPABLE[2]').
  at com.ibm.mq.MQMessage.readConvertedLine(MQMessage.java:3153)
  at com.ibm.mq.MQMessage.readLine(MQMessage.java:1426)
  ... ... ...
  
  
  When a migration from WebSphere Application Server v7.0.0.17 to
  V7.0.0.25 took place, the level of Java was also upgraded to the
  version containing the JRE APAR IV21353 which changes this
  CharsetDecoder behaviour. After receiving a message from
  WebSphere MQ, an application attempted to read the character
  content of the message which has been converted to the character
  set codepage "IBM930", WebSphere MQ classes for Java encountered
  this UNMAPPABLE exception.
  
  The consequence of this was that a null String object was
  returned to the application instead of the expect message
  content, and subsequent use of this object by the application
  resulted in a NullPointerException.
  
  Other than altering the character set which the data was
  converted to such that the bytes contained within the message
  could be represented in the character set, there is no mechanism
  to configure the WebSphere MQ classes for Java/JMS to return to
  the conversion behaviour prior to IV21353.
  

Problem conclusion

• To cater for this change in behaviour of the JRE, a code change
  has been made to the WebSphere MQ classes for Java at versions
  7.0, 7.1 and 7.5, which permits the configuration of the
  CharsetDecoder when working with byte sequences which cannot be
  represented in the target Charset.
  
  This behaviour can be controlled using two Java system
  properties, which are:
  
  
  com.ibm.mq.cfg.jmqi.UnmappableCharacterDecodeAction
  
  
  This Java system property takes a string argument which enables
  the "unmappable character decode actions" for the
  java.nio.charset.CharsetDecoder. If unmappable characters are
  found while decoding the message bytes, than this property can
  be set to following values to control the behaviour of the
  CharsetDecoder with respect to these unmappable characters.
  
  1. IGNORE:
  If this Java system property is set to value "IGNORE", for
  example by using the startup JVM argument:
  
   -Dcom.ibm.mq.cfg.jmqi.UnmappableCharacterDecodeAction="IGNORE"
  
  Then the unmappable characters will be dropped from the
  corresponding returned String object during the decoding
  operation.
  
  
  2. REPLACE:
  If the Java system property is set to value "REPLACE", for
  example by using the startup JVM argument:
  
  -Dcom.ibm.mq.cfg.jmqi.UnmappableCharacterDecodeAction="REPLACE"
  
  Then the default action is that the unmappable characters will
  be replaced by the JVM's default replacement character sequence,
  which is typically the Unicode "replacement character" character
  sequence:
  
      \uFFFD
  
  which has the byte sequence 0xFF 0xFD (fffd) when represented in
  the UTF-16 encoding, as used by JVM implementations.
  
  
  3. REPORT:
  If this Java system property is set to value "REPORT", for
  example by using the startup JVM argument:
  
  -Dcom.ibm.mq.cfg.jmqi.UnmappableCharacterDecodeAction="REPORT"
  
  Then an error will be generated by the CharsetDecoder object,
  which is reported back to the calling application via an
  "java.io.IOException" exception of the form:
  
   java.io.IOException: MQJE088: Decoding failed
  ('MQMessag2.readConvertedLine():UNMAPPABLE[1]').
  at com.ibm.mq.MQMessage.readConvertedLine(MQMessage.java:2936)
  at com.ibm.mq.MQMessage.readLine(MQMessage.java:1366)
  at my.application(MyApplication.java:100)
  
  
  The default behaviour when this property is not defined is the
  same as if the property had the value "REPORT", meaning that if
  an unmappable byte sequence is found, the data will not be
  converted into a character sequence and an error should be
  reported.
  
  To change this behaviour back to that seen on IBM JREs prior to
  the Java APAR IV21353 therefore, you set this property to the
  value "REPLACE", for example by using the startup JVM argument:
  
  
  -Dcom.ibm.mq.cfg.jmqi.UnmappableCharacterDecodeAction="REPLACE"
  
  
  
  A second property has also been added to the WebSphere MQ
  classes for Java API for the versions 7.0, 7.1 and 7.5. This is
  the property:
  
  com.ibm.mq.cfg.jmqi.UnmappableCharacterDecodeReplacement
  
  
  This Java system property provides the option to replace the
  unmappable sequence into user defined replacement characters,
  rather than the default Unicode "replacement character"
  '\ufffd'. This property takes a java.lang.String object as a
  value, although most JVM implementations will not permit more
  than one character to be in the String object. Its value must
  also not be null or have a non-zero length.
  
  In order for this second property to be effective, the first
  must also be set to "REPLACE" to enable the unmappable character
  action.
  
  For example, when receiving a message using the WebSphere MQ
  classes for Java which contains character data which cannot be
  represented within the JVM, in order to use a '?' character in
  place of these unmappable byte sequences you would use the JVM
  arguments:
  
  java
  -Dcom.ibm.mq.cfg.jmqi.UnmappableCharacterDecodeAction="REPLACE"
  
  -Dcom.ibm.mq.cfg.jmqi.UnmappableCharacterDecodeReplacement="?"
  
  
  where  is the class name of the application.
  
  
  
  The code change for WebSphere MQ classes for Java at the v8.0
  level differs from that above. As well as affecting the
  WebSphere MQ classes for Java API, at v8.0 the code has already
  been modified at the v8.0.0.1 level to alter the behaviour of
  the WebSphere MQ classes for JMS, for both encoding (creating
  messages to send to MQ) and decoding (receiving messages from
  MQ).
  
  To distinguish this behaviour from the v7 classes, the property
  name used to control the CharsetDecoder replacement function is:
  
  com.ibm.mq.cfg.jmqi.UnmappableCharacterAction
  
  This takes the same three values as above, being "REPLACE",
  "IGNORE" and "REPORT" (the default). It is not possible at the
  time of the creation of this APAR to alter the replacement
  character at the WebSphere MQ v8.0 version if the "REPLACE"
  option is selected.
  
  ---------------------------------------------------------------
  The fix is targeted for delivery in the following PTFs:
  
  Version    Maintenance Level
  v7.0       7.0.1.13
  v7.1       7.1.0.7
  v7.5       7.5.0.6
  v8.0       8.0.0.1
  
  The latest available maintenance can be obtained from
  'WebSphere MQ Recommended Fixes'
  http://www-1.ibm.com/support/docview.wss?rs=171&uid=swg27006037
  
  If the maintenance level is not yet available information on
  its planned availability can be found in 'WebSphere MQ
  Planned Maintenance Release Dates'
  http://www-1.ibm.com/support/docview.wss?rs=171&uid=swg27006309
  ---------------------------------------------------------------
  

Temporary fix

Comments

APAR Information

• APAR is sysrouted FROM one or more of the following:

• APAR is sysrouted TO one or more of the following:

Fix information

• Fixed component name

  WMQ AIX V7

• Fixed component ID

  5724H7221

Applicable component levels

• R701 PSY

     UP