Class loader questions, answers, and common problems for V4.0
 Technote (FAQ)
 
Problem
Common class loader questions and answers followed by a list of common problems for WebSphere® Application Server V4.0
 
Cause
This document identifies and addresses common class loader questions and problems.
 
Solution
If you do not find an answer to your question or a solution to your problem in this technote, you need to contact the support center. You can use the MustGather document for this component to collect essential information needed for troubleshooting. A link to this document appears at the bottom of this page.

Common Questions:

Q1. I want to use a different version of the xerces.jar or the xalan.jar files than the one shipped with WebSphere Application Server. How do I do this?

A1. Two options are available for configuring your Web application to use a different version of the xerces.jar or the xalan.jar files:

  • Package the updated xerces.jar or the xalan.jar files in the root of the enterprise application (.ear file). Each .ear file needs a copy of the .jar files. Use this approach only if you anticipate the need for multiple applications running on the same application server, using different versions of Xerces and Xalan.
  • Place the updated xerces.jar or xalan.jar file in the Websphere\Appserver\lib\app directory.

In either case, your application uses the updated versions of the xerces.jar or xalan.jar file and not the versions that WebSphere Application Server ships in the WebSphere\Appserver\lib directory.

Q2. What value do I set the module visibility to?

A2. See section 6.6.3.0: Application server properties in the WebSphere Application Server Information Center. This section describes the various visibility options.

Q3. Where do I place common class files that both my enterprise JavaBeans (EJBs) and Web modules (.war file) depend on?

A3. See section 6.4.1: Setting Classpaths in the information center. In this scenario, remember to place all of these common classes into a single .jar file. Add this .jar file to the enterprise application. Reference this .jar file in the MANIFEST class paths of both the EJB .jar file and the Web module. The MANIFEST file for the enterprise bean is located in the EJB .jar. The MANIFEST file for the web module is located in the WebSphere\Appserver\InstalledApss\name_of_EAR\name_of_WAR\META-INF directory.

Q4. How many class loaders are in each visibility mode?
A4. This answer is different for V4.02 and V4.03:

  • In V4.02, you have at least one class loader per module and one class loader per shared .jar file (any JAR file referenced by more than one module). This setup is true for all visibility modes.
  • In V4.03, it breaks down like this:

Server - One class loader for all application code

Compatibility - One class loader for all enterprise beans and dependency .jar files, one class loader for each Web module

Application - One class loader for each application (all Web modules, enterprise beans, and dependencies loaded by the single application class loader)

Module - Same as 4.02

J2EE - One class loader per application for enterprise bean and dependencies and one classloader for each Web module

Q5. What is the expected order of .jar and class loading if I have multiple enterprise beans and Web modules?
A5. In application mode, enterprise beans and Web modules are put into the class path search order, based on their appearance in the application.xml file.

Q6. What is the delegation mode (enterprise bean and .war) in application module visibility? What about the module?
A6. In application mode, set enterprise bean and .war delegation to be the same value or LinkageErrors result. In application mode, only the warDelegationMode mode is used to define the delegation mode for both enterprise beans and Web modules as they must be the same value. The value is set to true (parent first). In module mode, EJB delegation mode is set to true, while the Web module delegation mode is set to false (self first).

Q7. What is the search order of class paths?
A7. This order depends on the delegation mode. To get a better understanding of the WebSphere class paths and their search orders, consult section 6.4.1: Setting Classpaths in the V4.0 information center

Common Problems:

  1. ClassCastException

    Two potential causes for this error exist
    1. Customer code problem

      Take an example of two classes, Rectangle and Circle, that extend the class Shape. You create Rectangle and Circle objects and place them in a vector of type Shape. You pull an object off of the array of type Shape. The object is truly a circle, but at this time it is of type Shape. If you cast this object to type Rectangle, you get a ClassCastException exception.
    2. Class loader issue when the same class is loaded by two class loaders

      Example: A set of logs revealed a ClassCastException when loading a servlet. It becomes evident, after some debugging that the error was caused by one of the Java packages. Examining the packaged .jar file reveals that the .jar file contains the javax.swing classes. The J2EE.JAR file also contains the javax package. The javax classes are loaded by the WebSphere run-time class loader and the application class loader causing the ClassCastException exception.

  2. ClassNotFoundException

    Ensure the class that is not found is located within the class path. After getting this error, follow Part 3 of this document to see if the class is loaded in a class loader.
  3. NoClassDefFoundException

    This error usually means that the constructor of a class fails. Check the constructor of the class to see why it might have failed.
  4. java.lang.LinkageError : Class packageXXX/packageYYY/classZZZ violates loader constraints definition mismatch between parent and child

    A defect exists in the object request broker (ORB) for V4 (fixed in V5) that can potentially cause a problem when sharing a common object between class loaders. To resolve this problem, you need to perform the following two steps:
    1. Disable ClassSharing and put the .jar file that contains the common class in the $WAS_HOME/lib/app directory.

      To disable ClassSharing:
      1. Open the administrative client
      2. Navigate to the Application Server and select it
      3. Click the JVM Settings tab
      4. Click the Add button for System Properties.
      5. Add the following parameters: <name> com.ibm.ws.classloader.classSharing and <value> false
      6. Click Apply.
      7. Restart the Application Server.
    2. Change the module visibility mode for the Application Server to compatibility (not the preferred fix)
 
Related information
MustGather: Classloader Problem Determination on V4.0
 
 
 


Document Information


Product categories: Software > Application Servers > Distributed Application & Web Servers > WebSphere Application Server > Classloader
Operating system(s): HP-UX
Software version: 4.0
Software edition:
Reference #: 1158290
IBM Group: Software Group
Modified date: Jan 19, 2004