Here's my situation:
I set the classpath on my server to nothing. Here is my server command line:
java -Djava.security.policy=file:///c:\server\db.policy -Djava.rmi.server.codebase=file:/server.jar -jar server.jar C:\Project\db.db
I had the drive letter c:\ in the codebase but I read somewhere that a drive letter is a badly formed url, so I took it out. Whatever. Didn't help.
My main method in the server bundle contains these lines:
System.setSecurityManager(new RMISecurityManager());
LocateRegistry.createRegistry(1099); // loads the rmiregistry
FBNServer._rmiServ = new RMIServerImplementation(dbname); //static implementation of the interface
Naming.rebind("/FBNServer", _rmiServ );
On the client machine, I set the classpath to nothing (or client.jar, same results). The command line looks like this:
java -Djava.security.policy=file:///c:\client\db.policy -Djava.rmi.server.codebase=rmi://ipadd/FBNServer/ -jar client.jar -remote
ipaddress The naming lookup line looks like this:
_rmiInterface = (RMIInterface)Naming.lookup("rmi://
ip/FBNServer");
I'm still getting the Stub class not found error.
What I've tried:
- running the rmiregistry separately with no classpath and with the classpath to the server.jar.
- running the extracted jars with and without classpaths set.
- setting the codebase of the client to the server.jar, to the url:
rmi://ipadd/FBNServer/, and also not having a codebase.
- rmic-ing the Stub file with a classpath set to the server.jar, to the extracted classes directory, and with no classpath set.
The only thing that does work is if the client and server are running on the same machine. Rather useless for a distributed application
Does the Stub have to be in the client bundle in order for the program to work? If so, what the is the point of RMI if after every change to the server you have to build a new client and redistribute it. If not, why doesn't the stub get picked up by my client?