PQ79219: APPLICATION THAT CONTAINS A SERVLET PACKAGED WITH AN EJB INTERFACE REFERENCE FAILS WHEN IT LOADED BEFORE THE EJB | |||||||||||||||||||||||||||||||||||||||||
![]() |
|||||||||||||||||||||||||||||||||||||||||
![]() APAR status Closed as program error. Error description Customer has two applications. One that has a servlet and an ejb ("testservlet1") and another that has a servlet with interface references to that same ejb ("testservlet2") but not the ejb itself. When "testservlet2" is referenced first, the classloader cache has not been populated yet with the ejb classes. The failure observed can be: . Trace: 2003/09/25 17:38:40.763 01 t=9BC088 c=1.A key=P8 FunctionName: com.ibm.servlet.engine.srt.WebGroup SourceId: com.ibm.servlet.engine.srt.WebGroup Category: ERROR ExtendedMessage: Servlet Error: "Class <<app class name>> violates loader constraints: definition mismatch between parent and child loaders": java.lang.LinkageError: Class <<app class name>> violates loader constraints: definition mismatch between parent and child loaders . or . Trace: 2003/10/03 22:13:38.851 01 t=9D4E88 c=9.1 key=P8 FunctionName: com.ibm.servlet.engine.srt.WebGroup SourceId: com.ibm.servlet.engine.srt.WebGroup Category: ERROR ExtendedMessage: ***BUFFER OVERFLOW*** . or . java.lang.StackOverflowError exception . or . java.lang.ClassCastException exception . Please note that the presence of any of the above errors or exceptions alone does NOT match the symptoms of this apar. The packaging of the application needs to also match what is described by this apar. . There currently exists a jvm property: com.ibm.ws390.classloader.preload=true which currently works for classloader mode of compatibility or server but does not work for application. This apar will enable this existing property for application classloader mode. This apar, along with setting the above value in jvm.properties for the desired server, changes the default behavior. The default behavior is to load classes upon reference. With this apar and above property set, the behavior will be to load all classes during server initialization. . Keep in mind that using this property may impact the server startup time as all applications will be loaded during server initialization. The degree of the impact will depend on the number of applications and number of components in those applications. This may be necessary though if the applications must be packaged this way.Local fix If it's possible to repackage the application, one of the following may work: - Package the applications all together (i.e. in the above scenario, package both servlets and the ejb together) - Package the ejb with the servlet instead of the ejb reference, giving it a different home name. This would be just so the ejb's metadata is loaded when the servlet is loaded. The servlet would still reference the original home name.Problem summary **************************************************************** * USERS AFFECTED: All users of WebSphere Application Server * * version 4.0.1 for z/OS and OS/390. * **************************************************************** * PROBLEM DESCRIPTION: When an application that has a * * component ("compa") that contains * * interface references only to another * * component ("compb") and this * * application is loaded before the * * application that contains the * * referenced component, "compb" , * * classes cannot be resolved because the * * WebSphere class cache has not been * * loaded yet with "compb" classes. This * * surfaces in a variety of messages: * * java.lang.ClassCastException or * * "***BUFFER OVERFLOW***" or: * * "Class <<app class name>> violates * * loader constraints: definition * * mismatch between parent and child * * loaders". * * The above messages alone are not a * * match for this problem. The * * packaging of the application must * * also match the description above. * **************************************************************** * RECOMMENDATION: * **************************************************************** Support existed for jvm property com.ibm.ws390.classloader.preload such that when it was set to true, all applications would be loaded during server initialization rather than the default classloading behavior which is load the applications as they are referenced. Some applications, because of the way that they are packaged will need to be loaded all during initialization rather than the default behavior of being loaded on reference. The existing jvm property, com.ibm.ws390.classloader.preload, could previously only be set for classloader modes of server or compatibility. This apar allows it to be used for classloader mode of application as well.Problem conclusion Updated WS390ApplicationManager code to allow the com.ibm.ws390.classloader.preload property to be set for classloader mode of application. APAR PQ79219 is associated with SERVICE LEVEL W401604 of WebSphere Application Server version 4.0.1 for z/OS and OS/390.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
|
Document Information |
Product categories: Software > Application Servers >
Distributed Application & Web Servers > WebSphere Application
Server for z/OS
Operating system(s):
Software version: 401
Software edition:
Reference #: PQ79219
IBM Group: Software Group
Modified date: Nov 2, 2003
(C) Copyright IBM Corporation 2000, 2006. All Rights Reserved.