This week's book giveaway is in the Mac OS forum. We're giving away four copies of a choice of "Take Control of Upgrading to Yosemite" or "Take Control of Automating Your Mac" and have Joe Kissell on-line! See this thread for details.
All java source code has the following package statememt: package rmi.hello;
Source for HelloServer had the following: Naming.rebind("//localhost/HelloServer", obj);
Following is the dos commands I am running: D:\> start rmiregistry D:\Java\public_html\classes> java -Djava.rmi.server.codebase=http://localhost/HelloServer/ -Djava.security.policy="C:\Program Files\Java\jdk1.5.0\jre\lib\security\javaRMI.policy" rmi.hello.HelloServer
Codebase is like the classpath - if you have a http server running with a jar file out there somewhere, you can point to it using a HTTP:// URL and the RMI client will download it dynamically. If (in your case) it's a file on the machine somewhere you can use file:///C:/whatever/ to point to it. From the example command line you gave, it looks like you're confusing the codebase and the name in the RMI naming server where your instance is bound.
Write once, run anywhere, because there's nowhere to hide! - /. A.C.
Joined: Mar 11, 2005
Thanks, makes perfect sense, but I didn't see that stated anywhere. Does that mean I also need to do the same for the rebind statement?
The argument to rebind (and lookup, and bind) deals with *where* to bind (or find, in the case of lookup) the *running instance* of the service you want, and it looks something like this:
If you leave off the protocol portion it assumes it's "rmi://". If you leave off the address portion it assumes it's "localhost". If you leave off the port portion it assumes it's ":1099". The name portion is always required.
Think of the RMI registry like this... a set of hashtables, each running on a different machine. The "rmi://address:port/" points to the specific hashtable/machine, and the "name" portion provides a "key" to the service you want. [ March 15, 2005: Message edited by: Nathan Pruett ]