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:
- ClassCastException
Two potential causes for this error exist
- 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.
- 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.
- 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.
- 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.
- 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:
- Disable ClassSharing and put the .jar file that contains the common
class in the $WAS_HOME/lib/app directory.
To disable ClassSharing:
- Open the administrative client
- Navigate to the Application Server and select it
- Click the JVM Settings tab
- Click the Add button for System Properties.
- Add the following parameters: <name>
com.ibm.ws.classloader.classSharing and <value> false
- Click Apply.
- Restart the Application Server.
- Change the module visibility mode for the Application Server to
compatibility (not the preferred fix)
|