Hello,
I opened JIRA JBAS-4732 and was asked to open a forum thread in addition. That was my description:

For multihomed servers, it is essential to be able to bind JBoss services to dedicated interfaces (bind address). This requirement is fulfilled by jboss service Naming, and all other services known to the author, but not HAJNDI.
Since this is an inconsistency in implementing the design, I classify this to be a bug.
<br>
Affected source files:
$JBOSS_SRC/cluster/src/main/org/jboss/ha/jndi/HANamingServiceMBean.java
$JBOSS_SRC/cluster/src/main/org/jboss/ha/jndi/HANamingService.java

Comment by Brian Stansberry [17/Sep/07 10:30 AM]

HANamingService exposes attributes "BindAddress" and "AutoDiscoveryBindAddress", both of which are by default set to whatever you set the -b startup switch to. Same as Naming and everything else.
Please open a forum thread to discuss if you are having issues with this.

Here we go: The point is, that the world is not so simplistic that it would be always enough to just modify jboss.bind.address and the problem of multihoming is solved. What if we want to bind different JBoss services to different LANs? AutoDiscoveryBindAddress is only a solution if multicast is available, which cannot be assumed.

I think you as providers of a general platform should simply acknowledge that there is such a requirement in the outside world and provide the possibility to define service binding to IP addresses in a per-service granularity.

PS: It should be noted, that it is a very weak concept of RMI which comes into play, if RmiBindAddress of Naming is not modified via the -b option, but directly in the XML file (already supported today). RMI allows to explicitely define the port where a server shall be exported, but not the IP address. To this end, JBoss uses a server socket factory (rg.jnp.server.Main.initJnpInvoker()), which is used on creation of the socket: DefaultSocketFactory passes RmiBindAddress to the constructor of ServerSocket.
However, RMI doesn`t know which IP address the such created socket was bound to, but instead relies on the system property java.rmi.server.hostname. JBoss does not check in the socket factory that the system property is set accordingly, either. If not set, RMI internally uses

InetAddress.getLocalHost().getHostAddress()

(sun.rmi.transport.tcp.TCPEndpoint.java), which may very well be different from RmiBindAddress.

Even worse, if such an RmiBindAddress is also configurable for HAJNDI, it must be assured by someone ("the JBoss user") that it equals RmiBindAddress defined for Naming (there is only one value possible for java.rmi.server.hostname!). This should be checked during JBoss startup.
Note that this remark is not really an argument against introducing RmiBindAddress for HAJNDI, since the same issue exists for all other RMI servers, including JRMPInvoker and JRMPInvokerHA.