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 is sysrouted FROM one or more of the following: APAR is sysrouted TO one or more of the following: Modules/Macros
Publications Referenced
|
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
(C) Copyright IBM Corporation 2000, 2008. All Rights Reserved.