PQ82806: application pick up wrong classloader when using 2 ear file on same server and forward request to each other.

APAR status
Closed as program error.

Error description
The testcase contains 2 application, Test1.ear and Test2.ear.
Test1.ear
has two session bean Alpha and Beta. Test2.ear has a sevlet,
TestMe.

A call is made from TestMe to Beta, than Beta to Alpha, when the
call returns from Alpha to Beta, Beta uses the classloader of
TestMe and the result is a ClassCastException in SystemOut.log
■05/09/03 14:45:59:734 EDT 7442092d ExceptionUtil E CNTR0020E:
Non-application exception occurred while processing method
"callMe"on bean "BeanId(ClassCast#ClassCastEJB.jar#Hello,null)".
Exception data:
java.lang.ClassCastException: com.rlaflamme.bean.TestBean
    at com.rlaflamme.ejb.HelloBean.callMe(HelloBean.java:59)
    at com.rlaflamme.ejb.EJSRemoteStatelessHello_48fee1ab.callMe
    (EJSRemoteStatelessHello_48fee1ab.java:26)
 at java.lang.reflect.Method.invoke(Native Method)
 at com.ibm.CORBA.iiop.ClientDelegate$3.run(ClientDelegate.
 at java.security.AccessController.doPrivileged(Native Method)
 at com.ibm.CORBA.iiop.ClientDelegate.invoke(ClientDelegate.java
    :1138)
It is possible that a SRVE0026E error will be logged if
the EJB is called from a servlet rather than from another
EJB.

- When bean reference is created and/or activated by the
container,
which is initiated from the generated code, a java object
(wrapper) is
returned to ORB/Object adapter.
- ORB will turn this object to a stub and return the stub to the
original caller.
- When ORB invokes a EJB method, the contract between ORB and
EJB
Container is that ORB must call the Object Resolver before the
preinvoke/postinvoke sequence is initiated.
- In the current problem condition, where the caller and callee
are in
the same JVM and hence the same thread/context classloader, it
looks
like the ORB has short-circuited the wrapper -> stub conversion
ocess.  - When a the EJB reference, that is NOT a stub, is
invoked the
Object resolver is NOT being called and as a result the context
classloader for each call frame is not handle proper. i.e. the
betaTest's class loader was popped off earlier in the alphaTest
method
call.
- To prove the hypothesis, we have experimented adding a object
to stub
conversion in the problem ejb ( returns a Alpha stub rather than
the
Alpha wrapper ) create method, the problem has been resolved.

There are possible 2 solutions to this problem:
1) Get the ejbdeploy to generate the wrapper to stub call in
PortableRemoteObject.toStub( wrapper ) or
2) ORB has to honor the contract between EJB Container and ORB
to make
sure the Object resolver is called regardless of if the object
being
called is a wrapper or its stub.

The 2nd method is the preferred options.
Local fix
test fix provided by ORB team.

This is jdk defect, sov defect 67048.  The fix for this defect
is in orb131_20031219.
For IBM jdks, this is in jdk 131_sr7.
Problem summary
****************************************************************
* USERS AFFECTED: All users of WebSphere Application Server    *
*                 releases 5.0.1, 5.0.2, 5.0.2.2, 5.1 .        *
****************************************************************
* PROBLEM DESCRIPTION: Applications pick up the wrong          *
*                      classloader when using 2 ear files on   *
*                      the same server and forwarding requests *
*                      to each other.                          *
****************************************************************
* RECOMMENDATION:                                              *
****************************************************************
Error Description:
The testcase contains 2 application, Test1.ear and Test2.ear.
Test1.ear has two session bean Alpha and Beta. Test2.ear has
a sevlet TestMe.

A call is made from TestMe to Beta, than Beta to Alpha, when
the call return from Alpha to Beta, Beta is seen using the
classloader of TestMe.

This shows from message printed in SystemOut.log and the output
on browser by TestMe (classloader of Beta has changed after
call return from Alpha).

More details:
- When bean reference is created and/or activated by the
  container, which is initiated from the generated code, a
  java object (wrapper) is returned to ORB/Object adapter.
- ORB will turn this object to a stub and return the stub to
  the original caller.
- When ORB invokes a EJB method, the contract between ORB and
  EJBContainer is that ORB must call the Object Resolver
  before the preinvoke/postinvoke sequence is initiated.
- In the current problem condition, where the caller and callee
  are in the same JVM and hence the same thread/context
  classloader, it looks like the ORB has short-circuited the
  wrapper -> stub conversion process.
- When the EJB reference, that is NOT a stub, is invoked the
  Object resolver is NOT being called and as a result the
  context classloader for each call frame is not handle proper.
  i.e. the betaTest's class loader was popped off earlier in
  the alphaTest method call.

To prove the hypothesis, we have experimented adding a object
to stub conversion in the problem ejb ( returns a Alpha stub
rather than the Alpha wrapper ) create method, the problem has
been resolved.
Problem conclusion
There are possible 2 solutions to this problem:
1) Get the ejbdeploy to generate the wrapper to stub call in
   PortableRemoteObject.toStub( wrapper ) or
2) ORB has to honor the contract between EJB Container and ORB
   to make sure the Object resolver is called regardless if
   the object being called is a wrapper or its stub.

This is fixed in JDK defect, SOV 67048.
Temporary fix Comments
APAR information
APAR number PQ82806
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 2004-01-05
Closed date 2004-01-15
Last modified date 2004-04-30

APAR is sysrouted FROM one or more of the following:

APAR is sysrouted TO one or more of the following:

Modules/Macros
java          

Publications Referenced

Fix information

Applicable component levels
R003 PSY    UP
R00A PSY    UP
R00H PSY    UP
R00I PSY    UP
R00P PSY    UP
R00S PSY    UP
R00W PSY    UP
R103 PSY    UP
R10A PSY    UP
R10H PSY    UP
R10I 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: 00W
Software edition:
Reference #: PQ82806
IBM Group: Software Group
Modified date: Apr 30, 2004