UnmarshalException ClassNotFoundException on method parameter

Question

Context:
- I am running the same app (MyApp.jar) on two machines; they communicate via RMI. Although they are both the same application, I will refer to the "client" and "server" app here, where the client app is that which is making the remote method call.
- The app uses a custom proprietary library Library.jar- The server app invokes a method in the library that initiates the RMI export of Foo and its registration with the remote RMI registry.
- The client app invokes a method in the library with a parameter x of type SomeParameterType. This method invocation causes the stub for remote object Foo to be looked up, and a remote method FooRemote#someMethod(SomeParamaterType) to be invoked passing parameter x.
Results:
- When parameter x is a subtype of SomeParameterType that is included in Library.jar, everything works fine
- When parameter x is a subtype of SomeParameterType that is defined at the app layer and NOT included in Library.jar, the following exception results:
java.rmi.ServerException: RemoteException occurred in server thread; nested exception is:
     java.rmi.UnmarshalException: error unmarshalling arguments; nested exception is:
     java.lang.ClassNotFoundException: myapp.SubtypeOfSomeParameterType (no security manager: RMI class loader disabled)I have verified that myapp.SubtypeOfSomeParameterType is in MyApp.jar on both machines.
Other considerations:
-     I am actually channeling RMI over a proprietary communications protocol, but I don�t think this should affect the unmarshalling on the server side
Questions:
-     Is it possible that the unmarshalling is using a class loader that only knows about classes in Library.jar, perhaps because the remote object was exported by a class in that library and not by a class at the app layer.
-     Is there something else I�m not considering?
P.S. I�m hoping for something good from that ejp guy. He seems pretty active on this forum.

Answer 1

OK, I got you. I'll suppose that you are familiar with the mechanics of class loading in Java. If not, then you may want to read the following article first:
http://www-128.ibm.com/developerworks/java/library/j-dyn0429/
The problems may arise if MyApp.jar and Library.jar are loaded by different class loaders on the server side. For example, let me assume that Library.jar is placed into the jre/lib/ext directory and MyApp.jar is placed into the classpath parameter in the command line. In that case, the classes from Library.jar will be loaded using the ExtClassLoader whereas the classes from the MyApp.jar will be loaded using the AppClassLoader, the ExtClassLoaded being actually the parent of the AppClassLoader.
Furthermore, let me assume that the thread exporting the remote server object from Library.jar had it's context class loader set to the ExtClassLoader at the moment it was exported. This can easily be done using the corresponding setter method of the Thread class (note that the main Thread of a standalone Java application has it's context class loader set to the AppClassLoader, what will also be the case for all threads spawned by the main thread unless the context class loader is explicitly set to a different value).
Now let's see what happens when a client makes a call to the server (without dynamic class loading). On the server side, the RMI engine reads bytes from the input stream and starts a thread for serving the request. The context class loader of this thread is the same one as the context class loader of the thread which exported the remote object. In this case, it's ExtClassLoader. So, the RMI engine will try to reconstruct the input parameter using the ExtClassLoader. But, hey, the required class is in the MyApp.jar, loaded by the AppClassLoader, it can not be loaded by the ExtClassLoader. This is where the ClassNotFoundException comes from.
So, here I've illustrated a scenario where you may get a ClassNotFoundException although it seems that all classes are available to the server. Your particular case may of course slightly differ from this scenario, but may have basically the same origin. I'd suggest you to analyse which classes are loaded by which class loaders on the server side and look whether context class loaders are changed for whatever reason.
Regards,
Miran