What kind of class-loading error do you see when you develop an application or start an installed application?
A class cast exception results when the following conditions exist and can be corrected by the following actions:
System.out.println( source.getClass().getName() + “:” + target.getClass().getName() );Or use a javap command. For example:
javap java.util.HashMap
Compiled from "HashMap.java"
public class java.util.HashMap extends java.util.AbstractMap
implements java.util.Map,java.lang.Cloneable,java.io.Serializable {
If there is more than one class loader listed, then the target class was loaded by more than one class loader. Because the source object is an instance of the target class, the class loader that loaded the source object class is different from the class loader that loaded the target class.
The narrow method must be invoked according to the EJB 2.0 programming model. In particular, the target class submitted to the narrow method must be the exact, most derived interface of the EJB. This also causes a class cast exception in the WebSphere Application Server runtime environment. Examine the application and determine whether the target class submitted to the narrow method is a super-interface of the EJB that is specified, not the exact EJB type; if so, modify the application to invoke narrow with the exact EJB interface.
Lastly, if a class cast exception occurs during a narrow operation, verify that the narrow method is being applied to the result of a remote EJB lookup, not to a local enterprise bean. A narrow is not used for local lookups. Examine the application or module deployment descriptor to ensure that the object being narrowed is not a local object.
A class not found exception results when the following conditions exist and can be corrected by the following actions:
If the JAR file is not in the list, the class likely is not in the logical class path, not readable or an alternate class is already loaded. Move the class to a location that enables it to be loaded.
To correct this problem, determine whether the class exists and whether the application is properly using the class loader API. Follow the steps in The class is not visible on the logical classpath of the context class loader to determine whether the class is loaded. If the class has not been loaded, attempt to correct the application and see if the class loads. If the class is in the class path with proper permission and is not being overridden by another factory class, examine the API used to load the class.
When the JVM loads class A using the WebSphere extensions class loader, it then attempts to load Class B using the same class loader and ultimately creates a class not found exception.
To correct this problem:
A no class definition found exception results when the following conditions exist and can be corrected by the following actions:
A linkage error results when the following conditions exist and can be corrected by the following actions:
Several user actions can result in a linkage error:
In general, the Java virtual machine invokes findLibrary() on the class loader xxx that loads the class that calls System.loadLibrary(). If xxx.findLibrary() fails, the Java virtual machine attempts to find the library using the JVM class loader, which searches the JVM library path. If the library cannot be found, the Java virtual machine creates an UnsatisfiedLinkError exception.
Thus, if a WebSphere class loader is intended to find a native library myNativeLib, the library must be visible on the nativelibpath of the class loader that loads the class that calls System.loadLibrary(myNativeLib). This practice is necessary or desirable in the following situation:
Ensure that the correct WebSphere class loader loads the class that calls System.loadLibrary() and that the native library is visible on the Native Library Path setting.
public class LibLoader {
static {System.loadLibrary(MyNativeLib);}
public LibLoader();
}
Classes within server-scoped libraries are loaded once for each server lifecycle, ensuring that the native library required by the application is loaded once for each Java virtual machine, regardless of the application’s life cycle.
Modify the platform-specific environment variable defining the Java library path (LIBPATH) to include the path containing the unresolved native library.