Fixes are available
8.5.5.9: WebSphere Application Server V8.5.5 Fix Pack 9
8.5.5.10: WebSphere Application Server V8.5.5 Fix Pack 10
8.5.5.11: WebSphere Application Server V8.5.5 Fix Pack 11
8.5.5.12: WebSphere Application Server V8.5.5 Fix Pack 12
8.5.5.13: WebSphere Application Server V8.5.5 Fix Pack 13
8.5.5.14: WebSphere Application Server V8.5.5 Fix Pack 14
8.5.5.15: WebSphere Application Server V8.5.5 Fix Pack 15
8.5.5.17: WebSphere Application Server V8.5.5 Fix Pack 17
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
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
Document Information
Modified date:
28 April 2022