PM19703: JMS BINDING CUSTOM WIRE FORMAT HANDLED INCORRECTLY / JMS BINDING<HEADERS> TAG MISSING AFTER EDITING COMPOSITION UNIT.

APAR status

• Closed as program error.

Error description

• There are two problems with Java Message Service (JMS) binding
  corrected with this update.
  
  1) When an Service Component Architecture (SCA) composite
  defines a custom wire format the SCA runtime may not process
  it properly, resulting in a potential ClassCastException.
  
  2) After updating a composite containing a JMS binding
  via wsadmin or the Administrative Console, the <headers> tag
  in the SCA .composite file may be removed. As a result,
  properties defined under operationProperties may not be
  written to the JMS message as JMS user properties. A
  configuration update to any portion of the composite may
  expose this problem, for example, updating a target URI for a
  default binding reference.
  

Local fix

Problem summary

• ****************************************************************
  * USERS AFFECTED:  Users of IBM WebSphere Application Server   *
  *                  V7 Feature Pack for Service Component       *
  *                  Architecture (SCA)                          *
  ****************************************************************
  * PROBLEM DESCRIPTION: There are three scenarios               *
  *                      addressed in this APAR:                 *
  *                                                              *
  *                      1) An SCA application with JMS          *
  *                      binding and a JMS custom wireformat     *
  *                      defined in both the request and         *
  *                      response fails to run due to a          *
  *                      ClassCastException.                     *
  *                                                              *
  *                      2) An SCA application with JMS          *
  *                      binding and a JMS custom wireformat     *
  *                      defined in the request throws a         *
  *                      ClassCastException after the JMS        *
  *                      binding information has been updated    *
  *                      via wsadmin or the Administration       *
  *                      Console.                                *
  *                                                              *
  *                      3) Header properties defined under an   *
  *                      operationalProperties element in        *
  *                      application with JMS bindings are       *
  *                      erased after the JMS binding            *
  *                      information has been updated            *
  *                      via wsadmin or the Administration       *
  *                      Console. There may be a behavior        *
  *                      change where properties defined under   *
  *                      operationProperties may not be          *
  *                      written to the JMS message as           *
  *                      JMS user properties.                    *
  ****************************************************************
  * RECOMMENDATION:                                              *
  ****************************************************************
  Issue #1 is the result of placing two JMS custom wireformat
  interceptors on the binding. The code currently doesn't have
  a mechanism to distinguish which interceptor is for the
  request and which interceptor is for the response. As a
  result, the data transformation is attempted twice resulting
  in the following exception:
  
  FFDC Exception:java.lang.ClassCastException
  SourceId:org.apache.tuscany.sca.binding.jms.provider.RRBJMSBindi
  ngInvoker ProbeId:250
  Reporter:org.apache.tuscany.sca.binding.jms.provider.RRBJMSBindi
  ngInvoker@29d029d
  java.lang.ClassCastException:
  com.ibm.ws.sib.api.jms.impl.JmsObjectMessageImpl incompatible
  with [Ljava.lang.Object;
   at
  org.apache.tuscany.sca.binding.jms.wireformat.custom.runtime.Wir
  eFormatJMSCustomReferenceInterceptor.invokeRequest(WireFormatJMS
  CustomReferenceInterceptor.java:197)
   at
  org.apache.tuscany.sca.binding.jms.wireformat.custom.runtime.Wir
  eFormatJMSCustomReferenceInterceptor.invoke(WireFormatJMSCustomR
  eferenceInterceptor.java:135)
   at
  org.apache.tuscany.sca.binding.jms.wireformat.custom.runtime.Wir
  eFormatJMSCustomReferenceInterceptor.invoke(WireFormatJMSCustomR
  eferenceInterceptor.java:138)
   at
  org.apache.tuscany.sca.binding.jms.provider.RRBJMSBindingInvoker
  .invoke(RRBJMSBindingInvoker.java:230)
  
  
  Issue #2 is ultimately the same problem as #1 but isn't seen
  until the JMS binding is updated. Initially the composite for
  the application only contains one JMS custom wireformat. After
  the binding is updated, the composite is rewritten with a JMS
  custom wireformat element on both the request and response. The
  new composite file has an equivalent definition, however, due
  to issue #1, it is interpreted by the runtime differently.
  When the user attempts to run the application he will see the
  same error as seen in issue #1.
  
  In issue #3, the properties appear to have been erased
  because the header tag under operationProperties is removed
  after an update to the JMS binding. As a result, the component
  definition below:
  
  <component name="myJMSComponent">
        <implementation.java class="com.ibm.test.myJMSImpl"/>
        <reference name="myService">
              <interface.java
                  interface="com.ibm.test.myJMSService"/>
              <binding.jms>
                  <destination name="jms/Request" type="queue"/>
                  <operationProperties name="opProp1"
                      nativeOperation="native1">
                      <headers>
                          <property name="myProp1"
                              type="string">one</property>
                          <property name="myProp2"
                              type="string">two</property>
                      </headers>
                  </operationProperties>
              </binding.jms>
        </reference>
  </component>
  
  Will become:
  
  <component name="myJMSComponent">
        <implementation.java class="com.ibm.test.myJMSImpl"/>
        <reference name="myService">
              <interface.java
                  interface="com.ibm.test.myJMSService"/>
              <binding.jms>
                  <destination name="jms/Request" type="queue"/>
                  <operationProperties name="opProp1"
                      nativeOperation="native1">
                      <property name="myProp1"
                          type="string">one</property>
                      <property name="myProp2"
                          type="string">two</property>
                  </operationProperties>
              </binding.jms>
        </reference>
  </component>
  

Problem conclusion

• The Feature Pack for Service Component Architecture was
  changed to handle JMS custom wireformat on the request and
  response separately. Additionally, code was updated to
  properly write the <headers> tag under JMS binding
  operationProperties.
  
  APAR PM19703 is currently targeted for inclusion in Service
  Level (Fix Pack) 1.0.1.9 of WebSphere Application Server v7
  Feature Pack for Service Component Architecture (SCA) Refresh
  Pack. Please refer to the Recommended Updates page for
  delivery information:
  http://www.ibm.com/support/docview.wss?rs=180&uid=swg27004980
  

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

  WAS SCA FEATURE

• Fixed component ID

  5724J0854

Applicable component levels

• R700 PSY

     UP