I am VERY close to being finished with the assignment, I just have a slight problem with RMI...
My design is as follows: I use the "wrapper" design pattern. I have a ContractorServer interface, which the GUI always works against obviously.
The interface has one direct implementations: a LocalServer which handles all real communication with the Data class (backend). The ContractorServer then has an interface RMIServerInterface which extends ContractorServer, Remote. Finally I have RMI server implmentation called RMIServer which extends UnicastRemoteObject and obviously also implements the RMIServerInterface. The RMIServer wraps a local server and delegates all calls to it.
The server is created like so:
I THOUGHT this would mean that when the GUI called for instance the "find" method on the ContractorServer object, the object would be a ContractorServer interface stub, the stub would call back to the real RMIServer living on the server JVM, the RMIServer would call the LocalServer it is wrapping and all would work.
Connecting to the remote server works fine and I get a stub. But then when I try to call the "find" method, it seems the stub is trying to connect to "localhost", NOT back to the original server it came from. Running both client and server in two different JVMs on the same computer works, but not on two different since the stub (I think) keeps trying to contact only localhost.
Does your server have one static IP address, or does it have multiple and / or DHCP IP addresses assigned to it?
Instead of binding to RmiServerInterface.SERVER_RMI_NAME, try binding to "rmi://" + <server name or address> + ":" + java.rmi.registry.Registry.REGISTRY_PORT + "/" + RmiServerInterface.SERVER_RMI_NAME. You will then have specified that the server is on a specific host.
Thanks a lot for the help Andrew. You suggestion made my code clearer, but the error remained. You did make me consider that the error could be not in my code but the network, and it seems it is something with the network configuration on my Windows machine. When running it on a Linux box instead everything works as expected. I'm going to chance that my code is fine, and I'll submit the jar tonight,