Hi, I get the following exception when I use a Connection stub on the client side. java.rmi.UnmarshalException: error unmarshalling return; nested exception is: java.io.WriteAbortedException: Writing aborted by exception; java.io.NotSerializableException: javacert2.Connection This goes away if I extend UnicastRemoteObject in my Connection class. This is because UnicastRemoteObject extends Serializable. Here is what the JAVA 1.3 API says about this class: "Objects that require remote behavior should extend RemoteObject, typically via UnicastRemoteObject. If UnicastRemoteObject is not extended, the implementation class must then assume the responsibility for the correct semantics of the hashCode, equals, and toString methods inherited from the Object class, so that they behave appropriately for remote objects. " Since my Connection class extends UnicastRemoteobject, its constructor is required to throw RemoteException. Just wondering how is everyone else dealing with this? I get the impression some people are using Remote interface but not UnicastRemoteObject. Aruna.
Originally posted by Aruna Raghavan: I get the following exception when I use a Connection stub on the client side.
Actually, you are probably getting this exception when you are not using the Connection stub, but the ConnectionFactory tries to serialize the Connection back to the client instead of using a proper remote reference. In theory, you should be able to use UnicastRemoteObject.exportObject() to export your Connection as-is.
It doesn't, not so much because it extends Serializable, but because it is automatically exported as a proper remote object and therefore never serialized in the first place. Remote objects do not strictly need to be serializable; an object reference gets passed in their place. Only non-remote objects involved in an RMI method call are serialized.
Just wondering how is everyone else dealing with this?
Virtually everyone is simply extending UnicastRemoteObject for both ConnectionFactory and the Connection objects it creates. - Peter [ January 07, 2003: Message edited by: Peter den Haan ]