IBM Support

PI71999: XML transformer factory changed during server start

Fixes are available

17.0.0.1: WebSphere Application Server Liberty 17.0.0.1
17.0.0.2: WebSphere Application Server Liberty 17.0.0.2
17.0.0.3: WebSphere Application Server Liberty 17.0.0.3
17.0.0.4: WebSphere Application Server Liberty 17.0.0.4
18.0.0.1: WebSphere Application Server Liberty 18.0.0.1
18.0.0.2: WebSphere Application Server Liberty 18.0.0.2
18.0.0.3: WebSphere Application Server Liberty 18.0.0.3
18.0.0.4: WebSphere Application Server Liberty 18.0.0.4
19.0.0.1: WebSphere Application Server Liberty 19.0.0.1
19.0.0.2: WebSphere Application Server Liberty 19.0.0.2
19.0.0.3: WebSphere Application Server Liberty 19.0.0.3
19.0.0.4: WebSphere Application Server Liberty 19.0.0.4
19.0.0.5: WebSphere Application Server Liberty 19.0.0.5
19.0.0.6: WebSphere Application Server Liberty 19.0.0.6
19.0.0.7: WebSphere Application Server Liberty 19.0.0.7
19.0.0.8: WebSphere Application Server Liberty 19.0.0.8
19.0.0.9: WebSphere Application Server Liberty 19.0.0.9
19.0.0.10: WebSphere Application Server Liberty 19.0.0.10
19.0.0.11: WebSphere Application Server Liberty 19.0.0.11
19.0.0.12: WebSphere Application Server Liberty 19.0.0.12
20.0.0.1: WebSphere Application Server Liberty 20.0.0.1
20.0.0.2: WebSphere Application Server Liberty 20.0.0.2
20.0.0.3: WebSphere Application Server Liberty 20.0.0.3
20.0.0.4: WebSphere Application Server Liberty 20.0.0.4
20.0.0.5: WebSphere Application Server Liberty 20.0.0.5
20.0.0.6: WebSphere Application Server Liberty 20.0.0.6
20.0.0.7: WebSphere Application Server Liberty 20.0.0.7
20.0.0.8: WebSphere Application Server Liberty 20.0.0.8
20.0.0.9: WebSphere Application Server Liberty 20.0.0.9
20.0.0.10: WebSphere Application Server Liberty 20.0.0.10
20.0.0.11: WebSphere Application Server Liberty 20.0.0.11
20.0.0.12: WebSphere Application Server Liberty 20.0.0.12

Subscribe

You can track all active APARs for this component.

 

APAR status

  • Closed as program error.

Error description

  • A third-party library they are using needs to use a certain
    implementation of javax.xml.transform.TransformerFactory.
    The issue is that when
    com.ibm.ws.webcontainer.osgi.mbeans.PluginGenerator runs, it
    sets the IBM xml transformer with
    changeTransformerFactoryIfNeccessary() and reverts it back
    after plugin generation is done with
    revertTransformerFactoryIfNeccessary().
    
    Problem:
    revertTransformerFactoryIfNeccessary() assumes that it
    started with the IBM JDK default of
    com.ibm.xtq.xslt.jaxp.compiler.TransformerFactoryImpl, and
    always reverts to that impl.  Instead, it should save the
    original transformer factory being used, and restore it
    after plugin generation has completed.
    

Local fix

Problem summary

  • ****************************************************************
    * USERS AFFECTED:  Users of IBM WebSphere Application Server   *
    *                  Liberty with the IBM SDK                    *
    ****************************************************************
    * PROBLEM DESCRIPTION: When the IBM SDK is in use the jvm      *
    *                      property                                *
    *                      javax.xml.transform.TransformerFactory  *
    *                      is modified.                            *
    ****************************************************************
    * RECOMMENDATION:                                              *
    ****************************************************************
    When a plugin-cfg.xml file is generated for an application
    server, and the IBM JDK is in use, the WebContainer MBean, which
    performs the generation, temporarily sets the value of the jvm
    property javax.xml.transform.TransformerFactory to
    org.apache.xalan.processor.TransformerFactoryImpl in order to
    obtain a transformer factory to use . When complete it then
    changes the jvm property to
    com.ibm.xtq.xslt.jaxp.compiler.TransformerFactoryImpl, the
    normal java default,  but this will overwrites a previous
    different value set.
    
    This has always been a problem with the MBean but, as a result
    of changes made for the new pluginUtility command and automatic
    generation of a plugin-cfg.xml file in 16.0.0.3 , the MBean is
    now run during server start and for configuration updates,
    whereas previously it was only run on demand.  As a result the
    problem is more likely to occur from 16.0.0.3 and later.
    

Problem conclusion

  • The Mbean now restores the previous value of the jvm property
    after creating the TransformerFactory which ii uses to generate
    the plugin-cfg.xml file.
    
    The fix for this APAR is currently targeted for inclusion in fix
    pack 17.0.0.1.  Please refer to the Recommended Updates page for
    delivery information:
    http://www.ibm.com/support/docview.wss?rs=180&uid=swg27004980
    

Temporary fix

  • Manually set the JVM property to a desired value after starting
    a server or making a configuratuion update.
    

Comments

APAR Information

  • APAR number

    PI71999

  • Reported component name

    WAS LIBERTY COR

  • Reported component ID

    5725L2900

  • Reported release

    CD0

  • Status

    CLOSED PER

  • PE

    NoPE

  • HIPER

    NoHIPER

  • Special Attention

    NoSpecatt / Xsystem

  • Submitted date

    2016-11-08

  • Closed date

    2017-02-09

  • Last modified date

    2017-02-09

  • 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 LIBERTY COR

  • Fixed component ID

    5725L2900

Applicable component levels

  • RCD0 PSY

       UP

[{"Business Unit":{"code":"BU053","label":"Cloud \u0026 Data Platform"},"Product":{"code":"SSD28V","label":"WebSphere Application Server Liberty Core"},"Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"CD0","Line of Business":{"code":"LOB36","label":"IBM Automation"}}]

Document Information

Modified date:
19 October 2021