There seems to be a bug in org.jboss.invocation.InvokerInterceptor.isLocal(Invocation). Or at least I am unable to figure out how naming lookups from one JBoss instance to another are supposed to work with this code in InvokerInterceptor:
public boolean isLocal(Invocation invocation)
return localInvoker != null && Registry.lookup(invocation.getObjectName()) != null;
When NamingServer is bound in Registry in all instances with the same id:
14:17:59,704 DEBUG [HttpProxyFactory] Created HttpInvokerProxy for invoker=jboss:service=Naming, nameHash=349114835
And when cluster B tries to look up cluster A's naming server in order to find the session bean for which it works as a delegate, Registry always finds the naming server which exists in cluster B with the same id.
Working code from 3.2.5 InvokerInterceptor:
public boolean isLocal()
I'll write my own implementation of InvokerInterceptor for use in delegate bean lookups, and a LocalInvoker which sets local invoker instance in this custom InvokerInterceptor instance. What I would like to know is am I right, whether what I found is a bug, should I report it, and is there possible problems with reverting to 3.2.5 behaviour for InvokerInterceptor.isLocal().