PI83239: AFTER UPGRADE TO WEBSPHERE 8.5, SOME APPLICATIONS USING JAXB CLASSES HAVE NOCLASSDEFFOUNDERROR MESSAGES

8.5.5.15: WebSphere Application Server V8.5.5 Fix Pack 15
9.0.0.11: WebSphere Application Server traditional V9.0 Fix Pack 11
9.0.5.0: WebSphere Application Server traditional Version 9.0.5 Refresh Pack
9.0.5.1: WebSphere Application Server traditional Version 9.0.5 Fix Pack 1
9.0.5.2: WebSphere Application Server traditional Version 9.0.5 Fix Pack 2
8.5.5.17: WebSphere Application Server V8.5.5 Fix Pack 17
9.0.5.3: WebSphere Application Server traditional Version 9.0.5 Fix Pack 3
8.5.5.20: WebSphere Application Server V8.5.5.20
8.5.5.18: WebSphere Application Server V8.5.5 Fix Pack 18
8.5.5.19: WebSphere Application Server V8.5.5 Fix Pack 19
8.5.5.16: WebSphere Application Server V8.5.5 Fix Pack 16
8.5.5.21: WebSphere Application Server V8.5.5.21

APAR status

• Closed as program error.

Error description

• after setting this switch:
  -verbose:class
   And adding tracestring:
        Com.ibm.ws.classloader.*=all
  
  In the trace result on can see there is a difference scenarios
  with the load of the JAXB provider between the 8.0 and 8.5.5
  environments - specifically, the implementation class for
  javax.xml.bind.DatatypeConverter.  In the 8.0 environment, the
  implementation class appears to be
  com.ibm.jtc.jax.xml.bind.DatatypeConverterImpl, while in the
  8.5.5 environment it is javax.xml.bind.DatatypeConverterImpl.
  The former class appears to be either avoiding the
  instantiation of the JAXP class or somehow being instantiated
  in a context in which it does not have access to the
  application JAXP library.
  

Local fix

• Remove JAXB  in the application packaging.
  

Problem summary

• ****************************************************************
  * USERS AFFECTED:  IBM WebSphere Application Server (WAS)      *
  *                  users of the memory leak detection policy   *
  *                  and JAXB.                                   *
  ****************************************************************
  * PROBLEM DESCRIPTION: A classloader memory leak occurs        *
  *                      when an application uses the JAXB API   *
  *                      provided by the WAS and provides a      *
  *                      JAXP implementation.                    *
  ****************************************************************
  * RECOMMENDATION:                                              *
  ****************************************************************
  A classloader memory leak may occur when an application
  uses the JAXB API provided by WebSphere Application Server
  (WAS) and also provides a JAXP implementation, such as Xerces.
  A problematic reference chain occurs when the
  JAXB API javax.xml.bind.DatatypeConverter class initializes
  its static datatypeConverter field to an instance of
  javax.xml.bind.DatatypeConverterImpl that, during static
  initialization, loads and sets its datatypeFactory
  field to an instance of JAXP class
  javax.xml.bind.DatatypeFactoryImpl that is provided by the
  application rather than by WAS.
  Keeping with the Xerces example, the DatatypeFactory
  implementation class could be
  org.apache.xerces.jaxp.datatype.DatatypeFactoryImpl. Whatever
  the JAXP implementation may be, the datatypeConverter field
  indirectly references a class loaded by an application
  classloader, and neither the application classloader nor the
  classes it loaded can be collected from the heap after the
  application is stopped.
  APAR PI83239 enables WAS to prevent this problematic reference
  chain by ensuring, early in the server lifecycle, that the
  WAS JAXB-API DatatypeConverter references a JAXP
  DatatypeFactoryImpl class provided by WAS rather than the
  an application.
  This new "JAXB DatatypeConverter" protection adds to the
  JRE Memory Leak prevention feature provided by the Memory
  Leak Detection Policy documented in the WebSphere
  Application Server Knowledge Center:
  https://www.ibm.com/support/knowledgecenter/en/SSEQTP_8.5.5/com.
  ibm.websphere.base.iseries.doc/ae/ttrb_configmemleak.html
  To enable JRE memory leak prevention, including the new JAXB
  DataConverter protection, set the following JVM custom
  property to true:
  com.ibm.ws.runtime.component.MemoryLeakConfig.preventJreMemoryL
  eaks
  If the JAXB DatatypeConverter protection causes a problem with
  your application and you want to use JRE memory leak
  prevention, you can disable the protection by setting the
  following JVM custom property to false:
  com.ibm.ws.runtime.jaxbDatatypeConverterProtection
  

Problem conclusion

• Apply APAR PI83239 to enable WAS to protect against
  classloader memory leaks due to applications that use the JAXB
  API provided by WebSphere and also provide a JAXP
  implementation.
  
  The fix for this APAR is currently targeted for inclusion in
  fix packs 8.5.5.15 and 9.0.0.11.  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

  WEBSPHERE FOR Z

• Fixed component ID

  5655I3500

Applicable component levels

• R850 PSY

     UP