PQ72184: EJB handles cannot be persisted with a subclass of ObjectInputStr being created.

 Fixes are available

5.0.1: WebSphere Application Server Version 5.0 Fix Pack 1 (Version 5.0.1)
5.0.1: WebSphere Application Server Enterprise Edition Version 5.0 Fix Pack 1



APAR status
Closed as program error.

Error description
WebSphere users who try to read a persistent handle without
subclassing ObjectInputStream receive ClassNotFoundException
Application stores an EJBHandle in the HttpSession or in the
HttpRequest and attempts to instantiate it in another servlet or
EJB using a java.io.ObjectInputStream, then a
java.lang.Exception will occur unless a customized
ObjectInputStream is used that specifies to use the context
class loader to instantiate the object.
.
A problem with the EJBHandle class prevents the deserializing of
a handle using a standard java.io.ObjectInputStream unless a
stub class and the EJB handle implementation classes are loaded
by the same classloader.  The implementation of the callstack
for the first non-null classloader in the ObjectInpuStream class
creates this limitation in WebSphere Application Server v5.0.
.
An exception like the following may occur:
HandleDelegat > readEJBObject
java.lang.ClassNotFoundException: com.companyName._Session_Stub
 at java.net.URLClassLoader.findClass(URLClassLoader.java)
 at
com.ibm.ws.bootstrap.ExtClassLoader.findClass(ExtClassLoader.jav
a)
 at java.lang.ClassLoader.loadClass(ClassLoader.java)
 at java.lang.ClassLoader.loadClass(ClassLoader.java)
 at java.lang.Class.forName0(Native Method)
 at java.lang.Class.forName(Class.java)
 at
java.io.ObjectInputStream.resolveClass(ObjectInputStream.java:69
0)
 at
java.io.ObjectInputStream.inputClassDescriptor(ObjectInputStream
.java)
 at java.io.ObjectInputStream.readObject(ObjectInputStream.java)
 at java.io.ObjectInputStream.readObject(ObjectInputStream.java)
 at
java.io.ObjectInputStream.inputObject(ObjectInputStream.java)
 at java.io.ObjectInputStream.readObject(ObjectInputStream.java)
 at java.io.ObjectInputStream.readObject(ObjectInputStream.java)
 at
com.ibm.ejs.csi.HandleDelegateImpl.readEJBObject(HandleDelegateI
mpl.java)
 at
com.ibm.ws.ejb.portable.HandleImpl.readObject(HandleImpl.java)
Local fix
One can workaround the problem by using a custom
ObjectInputStream that uses the contextclassloader instead of
the latest user defined loader.
The following could be used in place of the
java.io.ObjectInputStream in the customer code.

****************************************************************
**
public class CCLObjectInputStream extends
java.io.ObjectInputStream {
  protected ClassLoader classloader;

  public CCLObjectInputStream(InputStream is)
    throws IOException {
    this(is, Thread.currentThread().getContextClassLoader());
  }

  public CCLObjectInputStream(InputStream is, ClassLoader cl)
    throws IOException {
    super(is);
    classloader = cl;
  }

  protected Class resolveClass(ObjectStreamClass objStrmClass)
    throws IOException,
           ClassNotFoundException
  {
    return classloader.loadClass(objStrmClass.getName());
  }
}
****************************************************************
**
Problem summary
****************************************************************
* USERS AFFECTED: WebSphere Application Server users who       *
*                 attempt to serialize and deserialize         *
*                 Handles from servlets or EJBS                *
****************************************************************
* PROBLEM DESCRIPTION: Classloader problems with               *
*                      ObjectInputStream prevents              *
*                      deserialization of Handles using the    *
*                      stub of the Object or Home.             *
****************************************************************
* RECOMMENDATION:                                              *
****************************************************************
If ObjectInputStream is used, users no longer have to subclass
ObjectInputStream or use newer release of IBMOrb.jar.  These
Handles serialize without those steps.  Release notes for 5.0.1
should be consulted.
Problem conclusion
Handle data was modified to avoid serialization, classloading,
and Orb issues.
Temporary fix Comments
APAR information
APAR number PQ72184
Reported component name WAS BASE 5.0
Reported component ID 5630A3600
Reported release 00W
Status CLOSED PER
PE NoPE
HIPER NoHIPER
Special Attention NoSpecatt
Submitted date 2003-03-18
Closed date 2003-05-16
Last modified date 2004-06-30

APAR is sysrouted FROM one or more of the following:

APAR is sysrouted TO one or more of the following:

Modules/Macros
EJBCONTR          

Publications Referenced

Fix information

Applicable component levels
R003 PSY    UP
R00A PSY    UP
R00H PSY    UP
R00I PSY    UP
R00S PSY    UP
R00W PSY    UP


Document Information


Product categories: Software > Application Servers > Distributed Application & Web Servers > WebSphere Application Server > General
Operating system(s):
Software version: 00W
Software edition:
Reference #: PQ72184
IBM Group: Software Group
Modified date: Jun 30, 2004