San Francisco rules!
Is it ok to call "UnicastRemoteObject.exportObject(this);" in the RemoteServiceImpl constructor to avoid RemoteServiceImpl "extends UnicastRemoteObject"?
Is it ok that RemoteServiceImpl does actually not redeclare the service methods incl. throwing RemoteException. Instead just the interface RemoteService declares the RemoteException??? That feels quite strange to me?
Question 3: Overall design approach? Any hints or recommendations?
Cheers, Roberto Perillo
SCJP, SCWCD, SCJD, SCBCD
You mean, on line 32 of your code? I don't think that is necessary because you are already doing so on line 58. I'm not sure though, because I didn't run this code...
Declaring a method in an interface with a throws clause means that the implementations can throw the listed exceptions, not that the implementations have to throw them. It's not strange
San Francisco rules!
Martin de Klaus wrote:Question 1: Is it ok to call "UnicastRemoteObject.exportObject(this);" in the RemoteServiceImpl constructor to avoid RemoteServiceImpl "extends UnicastRemoteObject"?
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.
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?