Questions regarding WebSphere Application Server V4.0.2 and V4.0.3 classloaders
 Technote (FAQ)
 
Problem
Where to find detailed information on the classloader works in WebSphere® Application Server V4.0?
 
Solution
Classloader function in WebSphere Application Server V4.0 is significantly different than previous WebSphere Application Server versions. The difference is primarily due to the implementation of J2EE within WebSphere Application Server V4.0.3.

The following white paper provides details on how the classloader works:
J2EE Class Loading Demystified

Note: This article applies primarily to version V4.0.1 and V4.0.2.

The details on the V4.0.3 classloader are in the V4.0.3 Release Notes. The following are more detailed questions raised after a customer's review of the article:
  1. Question:
    What is the official purpose of Java™ Virtual Machine (JVM™) classpath in WebSphere Application Server? Is it used for classes that use Java Native Interface (JNI)?

    Answer:
    Using the JVM classpath is not recommended. You can put JNI classes in any non-reloadable classloader. For example, ws.ext.dirs directories or websphere/appserver/lib/app.

  2. Question:
    What is the expected order of JAR/class loading if I have multiple EAR/ejbJAR/WAR/nonejbJAR files? What if manifest in different JARs mention the same JARs in a different order?

    Answer:
    Enterprise JavaBeans™ (EJB™) and WAR modules are put into the classpath search (for example, order for server visibility), based on the order applications are initialized in the system. The order within each application is determined by application.xml. The behavior is altered using the Visibility Mode, selected in the administrative console. In Application mode, EJBs and WAR modules are put into the classpath search order based on their appear in application.xml.

    Note: In the case of AEs, applications are initialized in the order they appear in server-cfg.xml.

  3. Question:
    How many classloaders do you truly have in each visibility mode?

    Answer:
    This answer is different for V4.0.2 and V4.0.3:
    • For version 4.0.2, you have at least 1 classloader per module and 1 classloader per shared JAR (any JAR referenced by more than one module). This is true for all visibility modes.

    • For version 4.0.3, it breaks down like this:
      • Server - 1 classloader for all application code.
      • Compatibility - 1 classloader for all EJBs and dependency JARs, 1 classloader for each Web module.
      • Application - 1 classloader for each application (all WAR and EJB dependencies loaded by the single application classloader).
      • Module - Same as V4.0.2.
      • J2EE - 1 classloader per application for EJB and dependencies, plus 1 classloader for each Web module.

Scenario:
  • Bean1 from EAR 1 calls bean2 from EAR 2 in same JVM with Application visibility.
  • Bean2 returns an object1 that was created in EAR2 classloader.
  • Object1 class is present in both EAR1 and EAR2.
  • If you try to use object1 in the bean1 classloader (for example: cast object1 to superclass you will get classCastError).
  • Will turning off noLocalCopies help?
    The answer is no. This is not a classloader issue, but an issue with the V4.0 ORB. We attempted to workaround this issue by implementing classSharing in the classloader so that in theory EAR1 and EAR2 would use the same class for Object1 (this is based on the EJB's home and remote interfaces). If you are passing a subclass of the type in your EJB's remote interface, you will experience this problem. You can either:
    • Switch to compatibility mode to solve the problem
    • Do not make inter-application EJB calls .
    • Future direction (a later release of WebSphere) is to modify ORB behavior to generate dynamic proxies to convert the objects.
During the customer's project several classloader issues impacted the development schedule. Here are some questions that resulted:
  1. Question:
    It appears the delegation mode flag for EJB modules defaults to false regardless with either WAR or EJB JAR modules. The Information Center disagrees with this observation. However, the delegation flag does default to true with Server visibility, as indicated by the Information Center.

    Answer:
    The Information Center is correct. Delegation mode will also be true in Compatibility and Module visibility modes. See #2 for more info.

    When module visibility is set to Application, the delegation flag com.ibm.ws.classloader.ejbDelegationMode is ignored by WebSphere Application Server..

    In Application mode, we must set EJB and WAR delegation to be the same value or LinkageErrors will result. In Application mode, only the warDelegationMode is used to define the delegation mode for both EJB and WAR modules, as they must be the same value.

  2. Question:
    Here is a more detailed question, based on the following example using ejbjar1, jarA and jarB:
    • Both jarA and jarB are unmodified JAR files included in the ejbjar1 manifest.
    • There is a dependency ejbjar1-->jarA-->jarB.
    • In Module visibility you will get classNotFound errors for classes in jarB.
    • I would expect module classloaders to always look into jarB even if classloading is initiated from jarA, since it is in ejbjar1 manifest.
    • Looks like even unmodified JARs have their own classloaders.
    • To solve this it appears you have to go to Application visibility or modify the manifest for unmodified JAR files.

Answer:
V4.0 implemented a strict dependency model in Module visibility mode. Here is a more concise scenario:
  • EJBJar1 has a dependency on JarA and JarB,
  • There also exists an unstated dependency between JarA and JarB.
  • This is one of the reasons we have deprecated Module visibility mode in V4.0.3, it is too complex to deal with the strict dependencies.
 
 
 


Document Information


Product categories: Software > Application Servers > Distributed Application & Web Servers > WebSphere Application Server > Classloader
Operating system(s): HP-UX
Software version: 4.0.1
Software edition:
Reference #: 1053145
IBM Group: Software Group
Modified date: Nov 3, 2003