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 at what level a class should be loaded at. 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 calling entity and the caller 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 “Custom class lists for packages, applications, or servers” 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 they were loaded at. 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. It will not do to refresh the components, package, or Web application directly.
