IBM Support

PI57314: JSP classloading ignores the application parent-last classloader setting

Subscribe

You can track all active APARs for this component.

 

APAR status

  • Closed as program error.

Error description

  • The issue is found on WAS 8.5.5.7
    
    RTC APAR defect 203248 will be available in 8.5.5.9.
    
    Currently the jsp classloader includes the jsp 2.2. bundle
    classloader as parent, which gives any jsp access to the
    entire jsp framework.  Since this includes the standard jstl
    library, it's not possible for parent-last classloading or
    osgi import-package to make the app use it's own copy of
    jstl. (this is the PMR).    The fix:
    
    -makes only the required jsp framework packages (such as the
    jsp superclass package) available to the jsp classloader
    through the TCCL
    - makes the standard jar etc available through the gateway
    classloader for ee apps; this allows the parent-last setting
    to load from the application
    - adds a backwards compatibility flag for the
    jspExtensionFactory (i.e., global) "osgiAppsCanProvideJSTL"
    set to false by default that (when false) exposes the
    standard jar packages to the jsp classloader as the parent
    classloader.
    - When the "osgiAppsCanProvideJSTL" flag is true, an osgi
    app that uses jsps will have to either explicitly import
    standard tag lib packages or include its' own copy.
    
    I believe that the only apps that will stop working with the
    default flag setting are those that are improperly accessing
    jsp framework internals.
    
    ee apps that include their own jstl and set parent-last
    classloading will now start working as configured.
    osgi apps that include their own jstl and use the default
    flag setting will continue to ignore the included jstl and
    use ours.
    
    osgi  apps that include their own jstl and use the
    non-default flag setting will start using the include jstl,
    presumably as intended.
    
    osgi apps that do not include their own  jstl and use the
    non-default flag setting will need to be changed to import
    any taglib packages the generated jsp code uses. (bnd can't
    help with this as the source is not available)
    

Local fix

  • The workaround is to use a shared library and remove the jstl
    spec api related libs from the war file.
    

Problem summary

  • ****************************************************************
    * USERS AFFECTED:  All users of IBM WebSphere Application      *
    *                  Server Liberty Profile                      *
    ****************************************************************
    * PROBLEM DESCRIPTION: JSP classloading ignores the            *
    *                      application parent-last classloader     *
    *                      setting                                 *
    ****************************************************************
    * RECOMMENDATION:                                              *
    ****************************************************************
    The JSP classloader ignores the parent-last application
    classloader setting, making it impossible to use an application-
    supplied tag library that is also supplied by Liberty, such as
    the JSTL library.  In addition, the JSP framework internal
    classes are exposed to JSPs, despite not being marked as API or
    SPI.
    

Problem conclusion

  • JSP classloading is corrected so that JSP framework internal
    classes are never exposed to JSP applications.  JSPs in JavaEE
    applications now respect the parent-last application classloader
    setting. By default, JSPs in OSGi applications always use the
    tag libraries supplied by Liberty.  In a Liberty server where
    you wish to supply non-default tag libraries in an OSGi
    application, the JSP framework may be configured with the
    osgiAppsCanProvideJSTL flag set to true.  In this case any OSGi
    applications that wish to use the Liberty-supplied libraries
    will need to explicitly import  the appropriate packages from
    the Liberty-supplied libraries.
    
    The fix for this APAR is currently targeted for inclusion in fix
    pack 8.5.5.9.  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 number

    PI57314

  • Reported component name

    WAS LIBERTY COR

  • Reported component ID

    5725L2900

  • Reported release

    855

  • Status

    CLOSED PER

  • PE

    NoPE

  • HIPER

    NoHIPER

  • Special Attention

    NoSpecatt / Xsystem

  • Submitted date

    2016-02-16

  • Closed date

    2016-02-25

  • Last modified date

    2016-02-25

  • 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

  • R855 PSY

       UP

[{"Line of Business":{"code":"LOB36","label":"IBM Automation"},"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":"855"}]

Document Information

Modified date:
07 September 2021