PQ56312: JSP 1.1 - RECURSIVE ERROR, INCOMPATIBLE OBJECT ARGUMENT FOR METHOD. | |||||||||||||||||||||||||
![]() |
|||||||||||||||||||||||||
APAR status Closed as documentation error. Error description Customer receives the following error in their application: - Servlet Error - "JSP 1.1 Processor" : "(class: jsp/ClauListarFecha_jsp_0, method: _jspService signature: (Ljavax/servlet/http/HttpServletRequest;Ljavax/servlet/http/ Incompatible object argument for method call": com.ibm.servlet.engine.webapp.WebAppErrorReport: (cla jsp/ClauListarFecha_jsp_0, method: _jspService signature: (Ljavax/servlet/http/HttpServletRequest; Ljavax/servlet/http/HttpServletResponse;)V) Incompatible ob argument for method call at com.ibm.servlet.engine.webapp.WebApp- DispatcherResponse.sendError(WebAppDispatcherResponse.java:1 at org.apache.jasper.runtime.JspServlet.unknownException(JspSer at org.apache.jasper.runtime.JspServlet.service(JspServlet.jav at javax.servlet.http.HttpServlet.service(HttpServlet.java:853 at com.ibm.servlet.engine.webapp.StrictServletInstance.doServiLocal fix Problem summary **************************************************************** * USERS AFFECTED: All users of the WebSphere Application * * Server Version 4.0.1 for z/OS and OS/390. * **************************************************************** * PROBLEM DESCRIPTION: The customer received the following * * error in their application: * * Servlet Error - "JSP 1.1 Processor" : * * "(class: jsp/ClauListarFecha_jsp_0, * * method: _jspService * * signature: * * (Ljavax/servlet/http/ * * HttpServletRequest;Ljavax/servlet * * /http/ * * Incompatible object argument for * * method * **************************************************************** * RECOMMENDATION: * **************************************************************** The customer received the following error in their application: Servlet Error - "JSP 1.1 Processor" : "(class: jsp/ClauListarFecha_jsp_0, method: _jspService signature: (Ljavax/servlet/http/HttpServletRequest;Ljavax/servlet /http/....) Incompatible object argument for method The customer in this case had specified his JAR file on the system classpath, which is not recommended. This problem was corrected when the customer was advised to modify the visibility mode for the J2EE Server from the default value (mode 1: compatibility mode) to mode 2, application mode. and to remove the JAR file from the system classpath. Changes that were made in recent PTFs to the behavior of the classloader for the WebSphere Application Server Version V4.0.1 for z/OS and OS/390 were not documented. This APAR was taken to document the changes.Problem conclusion The following changes will be made to Appendix A of WebSphere Application Server V4.0.1 for z/OS and OS/390: Assembling Java 2 Platform, Enterprise Edition (J2EE ) Applications: The description of the WS_EXT_DIRS environment variable will be changed to the following: WS_EXT_DIRS=name:name: ... Specifies the common JAR files and directories that can be accessed by multiple applications running in the same J2EE server instance. Normally JAR files listed on this environment variable reside outside of the Application Install directory. Each JAR file and directory in the list must be separated with a colon (:). Example: WS_EXT_DIRS=/tmp/aetna.jar:/tmp/ws_com_apps Notes: 1. JAR files that have the same classes as classes included in the WebSphere for z/OS runtime, such as xerces.jar and xalan.jar, can not be included on this environment variable. If they are included, the versions provided as part of the WebSphere for z/OS runtime will take precedence. 2. Application classes should not be manually added to the system classpath. If you have added application classes to the system classpath, they should be removed and specified on the WS_EXT_DIRS environment variable. Leaving application classes on the system classpath could have unpredictable results. The description of the com.ibm.ws390.server.classloadermode JVM property will be changed to the following: com.ibm.ws390.server.classloadermode=<number> Specifies the visibility mode to use for the J2EE server. The visibility mode determines which classloaders can be aware of other classloaders and of the application modules to be installed in the J2EE server. WebSphere for z/OS uses several different classloaders to install different module types: Modules for Enterprise beans Modules for Web applications, and Modules for WebSphere for z/OS run-time classes. Valid values (visibility modes) for this property are: 0 - specifies module mode, which allows WebSphere for z/OS to use only one classloader per module. Each module (JAR or WAR file) has its own unique classloader. Visibility of other modules in the application is achieved only when MANIFEST classpath entries are added to a module. 1 - specifies compatibility mode, which allows compatibility with applications from previous releases of WebSphere for z/OS. In this mode, all EJB module classloaders have visibility of all other EJB module classloaders, and all Web application modules have visibility of the EJB classloaders. The EJB classloaders are searched in the order in which the EJB modules were initialized. 2 - specifies application mode, which allows all classloaders in a J2EE application to have visibility of other classloaders in the same application. The search order is the same as the order in which the modules are defined in the application.xml for the EAR file. 3 - specifies server mode, which allows all application classloaders on the server to have visibility of all other application classloaders in the server. The search order is the same order as when the modules were initialized into the server. The default value is 1, compatibility mode. Notes: 1. MANIFEST classpath entries cannot be created as part of the application build process performed by the Application Assembly Tool provided with WebSphere for z/OS. If you want to include MANIFEST classpath entries, you must create your EAR file using a different tool, such as the IBM Studio Application Developer, and then use the AAT to install the application into the Web container. Existing MANIFEST classpath entries will be preserved during the installation process. 2. All application dependent files do not have to be included in each application s EAR file: If you are running with module mode (mode 0), compatibility mode (mode 1), or application mode (mode 2), files that are common to multiple applications can reside anywhere within the J2EE server instance, as long as they are listed on the WS_EXT_DIRS environment variable. The Web container and EJB container use the file and directory values specified on this environment variable to locate files not found with the application s EAR file. If you are running with server mode (mode 3), any application can find classes in any other application even if it is not specified on the WS_EXT_DIRS environment variable. All classes in any application are visible to all classes in any other application residing within the same J2EE server instance. The following note will be added to section "Steps for adding the J2SERV server" in Chapter 8 of WebSphere Application Server V4.0.1 for z/OS and OS/390: Assembling J2EE Applications: Note: Application classes should not be manually added to the system classpath. If you have added application classes to the system classpath, they should be removed and specified on the WS_EXT_DIRS environment variable. Leaving application classes on the system classpath could have unpredictable results. These changes affect COMPID 5655A9800 R401 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 #: PQ56312
IBM Group: Software Group
Modified date: Mar 26, 2002
(C) Copyright IBM Corporation 2000, 2006. All Rights Reserved.