RMI does not provide true location transparency , which means that you must at some point know the network name of the machine the server is running on. The server machine must be running the RMI registry program as well, though there’s no need for the RMI registry to be running on the client side.
Now the RMI registry needs to send the client stubs to the client. The best way to do this is to provide an HTTP URL and ensure that the stub files can be loaded from your web server. This can be done by passing the HTTP URL into the RMI server’s startup by defining it in the system properties:
java -Djava.rmi.server.codebase=http://serverhost/stubsdir/ ServerMain
In this example, serverhost
is the TCP/IP network name of the host where the RMI
server and registry are running, and stubsdir
is
some directory relative to the web server from which the stub files
can be downloaded.
Be careful to start the RMI registry in its own directory, away from where you are storing (or building!) the RMI stubs. If RMI can find the stubs in its own CLASSPATH, it will assume they are universally available and won’t download them!
The only other thing to do is to change the client’s view of the RMI lookup name to something like rmi://serverhost/foo_bar_name. And for security reasons, the installation of the RMI Security Manager, which was optional before, is now a requirement.
3.144.9.147