In JGroups 2.8, the Address type will typically not be IpAddress, so simply casting the Address to IpAddress and passing it to the ClusterNodeImpl ctor is invalid. The calling node needs to find the underlying InetAddress/port from the JGroups channel and pass the values to the constructor. Instead something like this needs to be done to get the IpAddress:

IpAddress physicalAddress = (IpAddress) channel.downcall(new Event(Event.GET_PHYSICAL_ADDRESS, a));

The ClusterNodeImpl.getOriginalJGAddress() method can be removed. It is not part of the ClusterNode interface, which is the API for this class.

It is tempting to remove the ClusterNodeImpl.originalJGAddress field and change the ClusterNodeImpl ctor to take InetAddress + port instead of IpAddress. However, this changes the serialization format of the class. We'd need to have a jboss-dev list discussion before doing that.

Eclipse reports 3 places where the ClusterNodeImpl ctor is called; 2 in ClusterPartition and one in RspFilterAdapter. RspFilterAdapter is called every time an RPC response comes in, so calling channel.downcall each time is clearly not reasonable. I think the thing to do is to find/cache in ClusterPartition the IpAddresses each time a new view comes in. In a ConcurrentMap<Address, IpAddress>. Then add a new IpAddressResolver interface that ClusterPartition implements by doing a map lookup or a channel.downcall is necessary. Probably better to use a separate class for this map/channel.downcall functionality. ClusterPartition will pass a ref to IpAddressResolver to any RspFilterAdapter it creates.