Announcement Announcement Module
No announcement yet.
Unmarshal Exception with RMI using spring Page Title Module
Move Remove Collapse
Conversation Detail Module
  • Filter
  • Time
  • Show
Clear All
new posts

  • Unmarshal Exception with RMI using spring

    I have 3 EAR's in my application all deployed on Websphere. These 3 ears are :
    ams.ear and ase.ear

    engine and ase both have a Spring based rmi service running on different ports. i.e. 8123 and 1099. Both these ears are deployed on different JVM's because JDK 1.4 has the limitation of not allowing more than one port for registry of RMI Services.

    ams.ear is just a client which uses the rmi services exposed by both the other ears and is deployed in the same JVM as ase.ear.

    When the client makes a call to the ase.ear, we get an unmarshalled exception for the serialized objects sent over RMI.

    My question is: we have a serial version id generated by Eclipse/IDE used, for each serializable object. How important/significant is it?

    Also, for this problem, all the objects which are sent over RMI are present as a shared library to both the ams and ase ear's, so there should not be any difference in the byte code.

    Looking at the unmarshalled exception, it looks as if the bytecodes for these serializable objects on the rmi server and client side are different, what have we done wrong? Is there a solution for this?

  • #2
    I found a solution for this problem. The problem is not with spring but with RMI. Spring RMI has the inbuilt ability of using Stubs , so we dont have to explicitly do that.

    The rmiregistry therefore, has a reference to all the methods registered in it. But we are passing serialized objects over rmi, then the RMI Server needs to have a reference or a way to identify these objects.

    Adding a JVM Argument of "-Djava.rmi.codebase=<path of the jar where the serialised objects are>". In websphere the deployed code will be present in the installedApps folder, so I gave this path of the jar and restarted the server. It worked after that.

    Also, second thing to be kept in mind, is the classloader of your application server. It is necessary that the classloading should happen in the below order:

    1. spring.jar
    2. library files required to compile the jar of the serialized objects
    3. jar of the serialized objects sent via RMI to the server from the client
    4. jar of the RMI Implementation classes.

    This should do the trick.