There seems to be a confusion of issues in this report.
By default, an RMI registry (such as one created with the LocateRegistry.createRegistry API), or any other exported remote object, receives calls on a server socket that is bound to all local network interfaces-- in IPv4 notation, for example, it is bound to the wildcard address 0.0.0.0. (This is why the client described in the report can reach the registry in order to perform a lookup.)
[ It is possible to create a registry that receives calls on a server socket bound to a specific local network interface, if binding to all of them is not desired: this can be achieved by passing a custom RMIServerSocketFactory to the LocateRegistry.createRegistry method. This technique is described in the following RMI-USERS thread:
But what it seems that the customer is really seeking is a way to control the host name or IP address that gets placed in the remote stub for an exported remote object (this has nothing to do with the registry):
By default, the host value placed in the remote stub for an exported remote object is the IP address of the InetAddress returned from an invocation of the InetAddress.getLocalHost method.
This default can be overridden by setting the system property "java.rmi.server.hostname"-- if that system property is set, then its value is used as the host value placed in the remote stub for any exported remote objects. Its value can be either a host name (to be resolved by any calling client's name services) or a specific numeric IP address. If, for example, there is a single host name that resolves to the correct IP address for all clients (on both sides of the multi-homed machine), then the "java.rmi.server.hostname" system property should be set to that host name.
(In J2SE 1.4 and beyond, the value of the "java.rmi.server.hostname" system property is resampled at every remote object export, so it is possible to export multiple remote objects in the same VM with different host values in their corresponding remote stubs.)
[ For a list of system properties supported by Sun's RMI implementation, see the following pages from the J2SE RMI documentation bundle:
The disadvantage of using the "java.rmi.server.hostname" system property is that it is a VM-global value, and thus it is not safe for independent, concurrent use by multiple parties in the same VM.
If the VM-global nature of the "java.rmi.server.hostname" system property is a problem, then the most flexible approach is to export remote objects with a custom RMIClientSocketFactory that ignores the supplied host value in the remote stub and contains its own state for determining the appropriate host to connect to. This approach is described in the following RMI-USERS post:
It is conceivable that support for explicitly specifying a host value could be added to the various J2SE RMI APIs for exporting remote objects (UnicastRemoteObject.exportObject, Activatable.exportObject, etc.) at some point, but basically equivalent functionality can be achieved by exporting with a custom RMIClientSocketFactory already, as described in the above-mentioned post.
Note that a possible caveat to the flexible approach described above is that until bug 5052870 is fixed, the client-side permission requirements could be somewhat confusing, because the checkConnect performed for reused connections will be based on the standard host value in the remote stub.