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.doServi
Local 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 information
APAR number PQ56312
Reported component name WEBSPHERE OS/39
Reported component ID 5655A9800
Reported release 401
Status CLOSED DOC
PE NoPE
HIPER NoHIPER
Submitted date 2002-01-04
Closed date 2002-03-26
Last modified date 2002-03-26

APAR is sysrouted FROM one or more of the following:

APAR is sysrouted TO one or more of the following:

Modules/Macros

Fix information

Applicable component levels


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