PQ99840: WEBSERVICE CUSTOM CALLBACK CLASSNOTFOUNDEXCEPTION | |||||||||||||||||||||||||||||||||||||||||||||||
![]() |
|||||||||||||||||||||||||||||||||||||||||||||||
![]() APAR status Closed as fixed if next. Error description Webservice Custom Callback ClassNotFoundException Customer sees following exception when using a custom call back handlers: com.ibm.wsspi.wssecurity.SoapSecurityException: WSEC5089E: Unable to instantiate CallbackHandler: java.lang.ClassNotFoundException: au.gov.centrelink.appframework.ers.webservice.CustomBinaryTokenL oginModule Customer has tried using shared library for the utility jar file and also tried packaging it with the app but the problem still occurrs. The only know work around is to put the jar file in the lib/ext folder. On further investigation it was found that the reason there are no errors when putting the class in lib/ext is because the classloader in use is the bootstrap classloader. So the question is why is the WAS class loader trying to load an application class. Is there something specific for web services/security? WSEMFRequestSenderConfig class is being loaded by the WAS classlaoder which is then trying to load the CustomBinaryTokenLoginModule (packaged and referenced correctly per classloader specs). This class is packaged in a jar file that is placed at the root of the ear. The web module making reference to it has the correct classpath entry for it in the manifest file - so as far as the packaging goes it is correct. The testcase is on wasdoc1: \38\38004.999.616\12.10.04\Webservice.EARLocal fix 1. put the jar file in lib/ext folderProblem summary **************************************************************** * USERS AFFECTED: All WebSphere Application Server users * * deploying Java Authentication and * * Authorization Services (JAAS) login * * modules. * **************************************************************** * PROBLEM DESCRIPTION: com.ibm.wsspi.wssecurity. * * SoapSecurityException: WSEC5089E: * * Unable to instantiate CallbackHandler: * * java.lang.ClassNotFoundException: * **************************************************************** * RECOMMENDATION: * **************************************************************** com.ibm.wsspi.wssecurity.SoapSecurityException: WSEC5089E: Unable to instantiate CallbackHandler: java.lang.ClassNotFoundException: The above is received if JAAS login module callback handlers are configured for Web Services. This will occur if the JAAS login module is deployed using either of the documented methods which are with the application or as a Shared Library. The cause of the failure is in two parts. First, the context classloader has not been set on the thread of execution. Second, code used to instantiate the callback handler class does not use the thread context classloader. This issue is being addressed in 6.X. It is not being addressed in 5.X due to the test considerations. There is a significant possibility of breaking applications already deployed in the field with the necessary changes and the necessary changes cannot be tested sufficiently. The Info Center will be updated to reflect how to deploy a JAAS login module if it is to be used in Web Services. The basic instructions are to put all necessary files in java/jre/lib/extProblem conclusion Temporary fix Comments Use of first person ("we") is not appropriate. Also the known workaround of using shared libraries for the JAAS login module instead of deploying it with the application was not documented. Please reopen the APAR making the above corrections.
APAR is sysrouted FROM one or more of the following: APAR is sysrouted TO one or more of the following: PK00941 Modules/Macros Publications Referenced
|
Product categories: Software > Application Servers >
Distributed Application & Web Servers > WebSphere Application
Server > General
Operating system(s):
Software version: 10W
Software edition:
Reference #: PQ99840
IBM Group: Software Group
Modified date: Jun 1, 2005
(C) Copyright IBM Corporation 2000, 2008. All Rights Reserved.