This section presents additional information that can be useful when diagnosing class loader configuration problems.
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.
To troubleshoot class loader problems, you can enable custom class loader tracing by setting the server property com.sybase.jaguar.server.classloader.debug to true using the Advanced tab in the Server Properties dialog box.
JAR files that are in the server’s CLASSPATH setting are locked while in use by the system class loader. Consequently, on some platforms such as Windows, you cannot update or overwrite the JAR file while the server is running. To verify the server’s CLASSPATH setting, connect to the server with EAServer Manager and check the value in the General tab of the Server Properties dialog box, or connect to the server with jagtool and check the value of the server property com.sybase.jaguar.server.jvm.classpath.
To allow refresh of JAR files that are custom loaded, each class loader instance works with a copy of the JAR files that it has loaded. Copies are created in subdirectories of the EAServer work/server-name/tempjars subdirectory, where server-name is the name of your server. EAServer deletes these directories and files when you restart the server.
| Copyright © 2005. Sybase Inc. All rights reserved. |
|
|