Class Loader Issues in Published Projects
Careful inspection of the stack trace can provide you with helpful hints about Application Platform issues. The following points describe the most common cases:
ClassNotFoundException. A
java.lang.ClassNotFoundException usually indicates that a class within the bundle fails to instantiate a class, for example,
Class.forName, for one of the following reasons:
The class is not in the bundle that is raising the exception.
The class is not exported by any other bundle on the server.
The class is exported by a bundle on the server but the bundle that is raising the exception does not import the class.
Usually, this issue will not be caught when your project is published, as long as there is a source code reference to the class.
Note:
Jars that are added to a project's classpath through its \lib directory do not have its packages exported with the project bundle. This feature is intended as a means to extend a project bundle's classloader by including additional classes that are private to the project.
NoClassDefFoundError. A
java.lang.NoClassDefFoundError usually indicates that a class that is loaded in the bundle's classloader fails to reference another class while executing.
LinkageError and ClassCastException. These errors usually indicate classloader pollution. Under normal circumstances, a collection of related bundles can be represented by a dependency graph based upon the chain of package imports and exports formed between these bundles. You must ensure that within a specific graph only one instance of a class type is loaded and accessed across the graph. If there are multiple versions of the same class in the graph, then a
java.lang.LinkageError or a
java.lang.ClassCastException is produced.
Software AG Common Platform supports loading multiple versions of class instances in the JVM. However, you must ensure that one execution thread consistently uses the same class type. The OSGi Export-Package: header supports a uses directive to provide clarity in such cases.
For example, in the diagram below, bundle A imports a package from bundle B. One of the imported packages contains a class with a method signature that includes parameters found in bundle C version 1.1. At the same time, bundle A has dependencies to another version of bundle C, version 1.0, which leads to an invalid classloader graph.
Note:
If you are adding jars to a project's classpath through its \lib directory, make sure that containing classes are not already exported by another, similarly to the provided example.
