PQ99840: WEBSERVICE CUSTOM CALLBACK CLASSNOTFOUNDEXCEPTION

 Fixes are available

6.0.2: WebSphere Application Server V6.0 Refresh Pack 2 for AIX platforms
6.0.2: WebSphere Application Server V6.0 Refresh Pack 2 for HP-UX platforms
6.0.2: WebSphere Application Server V6.0 Refresh Pack 2 for OS/400 platforms
6.0.2: WebSphere Application Server V6.0 Refresh Pack 2 for Solaris platforms
6.0.2: WebSphere Application Server V6.0 Refresh Pack 2 for Windows platforms
6.0.2: WebSphere Application Server V6.0 Refresh Pack 2 for Linux platforms



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.EAR
Local fix
1. put the jar file in lib/ext folder
Problem 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/ext
Problem 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 information
APAR number PQ99840
Reported component name WAS BASE 5.0
Reported component ID 5630A3600
Reported release 10W
Status CLOSED FIN
PE NoPE
HIPER NoHIPER
Special Attention NoSpecatt
Submitted date 2005-01-21
Closed date 2005-02-11
Last modified date 2005-06-01

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

Fix information

Applicable component levels
R00A PSY    UP
R00H PSY    UP
R00P PSY    UP
R00S PSY    UP
R00W PSY    UP
R10A PSY    UP
R10H PSY    UP
R10P PSY    UP
R10S PSY    UP
R10W PSY    UP


Document Information


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