Martin de Klaus wrote:Question 1: Is it ok to call "UnicastRemoteObject.exportObject(this);" in the RemoteServiceImpl constructor to avoid RemoteServiceImpl "extends UnicastRemoteObject"?
From an OO perspective it's in my opinion much better to call
UnicastRemoteObject.exportObject(this); than extending
UnicastRemoteObject. Why? If you extend a class, you are actually creating a more specialized version of the base class with more specific behavior. But your
RemoteServiceImpl class doesn't do that I guess, it just wants to use the remote capabilities of that class. Another (obvious) reason (but for me less important than the 1st one):
Java doesn't support multiple inheritance, so if you extend
UnicastRemoteObject, you can't extend from another (business related) class.
Martin de Klaus wrote:Hmmm, Actually in line 32 the RemoteServiceImpl itself is exported.
In line 58 the RemoteServiceFACTORY is exported.
If I remove line 32, I recieve a java.io.NotSerializableException: RemoteServiceImpl. So I guess I need to export both, the RemoteServiceFactory and the RemoteServiceImpl.
I didn't implement a rmi factory myself, so no practical knowledge here. Just some (a little bit) common sense

If you get an exception when removing the line, I think it's really needed

But I wonder if the constructor is the right place to invoke that method

I would move that call to the
getRemoteService() method of the
RemoteServiceFactoryImpl class. Seems more logical to me.
Martin de Klaus wrote:That's obviously true
. I was just wondering, if the actual class method does not declare the RemoteException, even if the interface did so, how will a error during execution of a remote method call indicated? Or is this somehow handled by RMI itself?
Yes, that RemoteException is an RMI thingy

In my
SCJD days I had some fun playing around with all possible variants with Remote interface and RemoteException in method signature.
Here you'll find the results.
Hope it helps!