Fixes are available
PI23168;8.5.5: java.lang.classnotfoundexception in data sources after upgrade to
PI23168;8.5.5: java.lang.classnotfoundexception in data sources after upgrade to
8.5.5.4: WebSphere Application Server V8.5.5 Fix Pack 4
PI29911;8.5.5: Confidential for Security Integrity ifix
8.5.5.5: WebSphere Application Server V8.5.5 Fix Pack 5
8.5.5.6: WebSphere Application Server V8.5.5 Fix Pack 6
8.5.5.7: WebSphere Application Server V8.5.5 Fix Pack 7
8.5.5.8: WebSphere Application Server V8.5.5 Fix Pack 8
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.14: WebSphere Application Server V8.5.5 Fix Pack 14
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
After upgrading to WebSphere Application Server Liberty Edition 8.5.5.2, datasources may throw an exception like the following: Could not find datasource: jdbc/eIntake javax.naming.NamingException: CWWKN0008E: An object could not be obtained for name jdbc/datasource. at com.ibm.ws.jndi.internal.WSContext.resolveObject(WSContext.java: 125) at com.ibm.ws.jndi.internal.WSContext.lookup(WSContext.java:306) at com.ibm.ws.jndi.internal.WSContext.lookup(WSContext.java:301) at org.apache.aries.jndi.DelegateContext.lookup(DelegateContext.jav a:161) Caused by: java.lang.ClassNotFoundException: oracle.jdbc.pool.OracleConnectionPoolDataSource at com.ibm.ws.classloading.internal.AppClassLoader.findClassCommonL ibraryClassLoaders(AppClassLoader.java:403) at com.ibm.ws.classloading.internal.AppClassLoader.findClass(AppCla ss Loader.java:232) at java.lang.ClassLoader.loadClass(Unknown Source) at com.ibm.ws.classloading.internal.AppClassLoader.loadClass(AppCla ssLoader.java:378) at com.ibm.ws.jdbc.internal.JDBCDriverService$1.run(JDBCDriverServi ce.java:226) This is due to a defect in which an ID generated for nested library elements is the same across different <dataSource/> elements causing only one of them to be loaded.
Local fix
Set an ID on the nested <library/> element. As this will produce a warning from the WebSphere Developer Tools also move the <library/> elements to the top level and using a libraryRef inside the <jdbcDriver/> element to reference them
Problem summary
**************************************************************** * USERS AFFECTED: All users of IBM WebSphere Application * * Server Liberty Profile 8.5.5.3 using nested * * libraries * **************************************************************** * PROBLEM DESCRIPTION: ClassNotFoundExceptions occur where * * nested libraries are in use * **************************************************************** * RECOMMENDATION: * **************************************************************** Internal IDs generated for nested library elements in server.xml are the same across different elements causing only one of them to be loaded. This therefore leads to ClassNotFoundExceptions. For example when using configuration such as: <dataSource id="derbyWithNestedList" jndiName="jdbc/derbyWithNestedList"> <jdbcDriver> <library> <fileset dir="${server.config.dir}/derby"/> </library> </jdbcDriver> <properties.derby.embedded createDatabase="create" /> </dataSource> <dataSource id="db2WithNestedList" jndiName="jdbc/db2WithNestedList"> <jdbcDriver> <library> <fileset dir="${server.config.dir}/db2"/> </library> </jdbcDriver> <properties.db2.jcc /> </dataSource> the two nested libraries end up with the same internal ID which leads to problems when class loading.
Problem conclusion
The Liberty profile server has been changed so that unique IDs are generated for each nested library element in the server configuration. The fix for this APAR is currently targeted for inclusion in fix pack 8.5.5.4. Please refer to the Recommended Updates page for delivery information: http://www.ibm.com/support/docview.wss?rs=180&uid=swg27004980
Temporary fix
To work around this problem you can set an ID on the nested <library/> element. This workaround however will produce a warning from the WebSphere Developer Tools and to eliminate this you can also move the <library/> elements to the top level configuration and use a libraryRef inside the other elements to reference them (this will also remove some duplication from configuration files where the same library might be been defined more than once).
Comments
APAR Information
APAR number
PI23168
Reported component name
LIBERTY PROFILE
Reported component ID
5724J0814
Reported release
850
Status
CLOSED PER
PE
NoPE
HIPER
NoHIPER
Special Attention
NoSpecatt
Submitted date
2014-08-01
Closed date
2014-10-14
Last modified date
2014-11-10
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
LIBERTY PROFILE
Fixed component ID
5724J0814
Applicable component levels
R850 PSY
UP
Document Information
Modified date:
27 April 2022