Common problems encountered in the custom class list configuration include:
Class cast exceptions In Java, classes loaded by different class loaders are considered different types. You cannot assign a class loaded by one class loader to a reference loaded by another class loader. This restriction must be accounted for when specifying the custom class list, or when deciding the level at which a class should be loaded. Otherwise, the invocation may fail and you see one these Java exceptions in the server log file:
java.lang.ClassCastException
java.lang.LinkageError
java.lang.NoClassDefFoundError
java.lang.IncompatibleClassChangeError
There are two variations of this issue:
When using EJB local interfaces, the caller and the callee must share the same instance of classes that are passed as method parameters or return values. In this case, fix the problem by copying the relevant custom class list entries to parent entities, up to a common ancestor. See “Sharing custom-loaded classes” for details.
For other Java or EJB component calls, the entity that calls the component uses stubs that are system loaded. This call fails because stubs in the component are custom loaded, and Java considers classes that are loaded by different class loaders to be different types, even when the classes have the same name and deployment location. To fix this problem, add the called component’s stub classes to the custom class list for the component or Web application that makes the call.
Refreshing classes Classes must be refreshed at the level at which they were loaded. For example, if you configure an application class loader to share some class instances between components and Web applications, you must refresh the application to reload new versions of these classes. You cannot successfully refresh the components, package, or Web application directly.
