|
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:
- 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.
- 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.
- 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:
- 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.
- 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.
|
|
|
|
|
|
|