One possible solution -- the target id for the ProxyFactory can't be its JNDI name. It should be the ObjectName of the container + another attribute. For clustered beans, the partition name should be included as well.
Problem with this is the doesn't deal with the EJBTHREE-773 issue -- apparently customers wanted to deploy the same bean in the same package on node0 and node1. But if a client on node0 specifically looks up the bean on node1's JNDI, the call should go to the node1 bean.
JIRA for this is http://jira.jboss.com/jira/browse/EJBTHREE-925.
A fix that will give behavior consistent with the objective of EJBTHREE-773 is:
1) For clustered SFSBs, the StatefulClusterProxyFactory should be registered with the Dispatcher with a name like this:
container.getObjectName().getCanonicalName() + ",element=ProxyFactory,partition=" + container.getPartitionName()
With this, the call to the proxy factory will route locally if the target factory is associated with the same bean name in the same deployment package in the same cluster partition; otherwise it will go remote.
2) For non-clustered SFSBs, use of different partition names is not available as a means to distinguish two identical deployments on separate groups of servers. The stated objective of EJBTHREE-773 was to have the call go remote if this kind of deployment exists and the client does a lookup on a remote server, so:
a) The client interceptor stack for the ProxyFactory proxy will not include the o.j.aspects.IsLocalInterceptor. This should be fine. For this call there are no later client-side interceptors that should be bypassed if the call is local. And Remoting already detects if the call's InvokerLocator points to a local server, and bypasses any marshalling if it is. So, getting rid of this interceptor allows calls to go remote but shouldn't noticeably the handling of legitimate local calls.
b) the StatefulRemoteProxyFactory will be registered with the Dispatcher with a name like the above, minus the partition attribute. Given a) above this isn't really necessary, but it seems like a safer name (e.g. if someone some day restores the IsLocalInterceptor you won't end up with proxy creation calls going to completely unrelated beans.)
I've implented the above on my Branch_4_2 working copy and the tests I wrote that surfaced this now pass. I'm running the full ejb3 testsuite overnight; if no issues pop up I'll check it in in the morning.
Went away from the non-clustered approach described in 2a) above to use a new IsLocalProxyFactoryInterceptor that only routes locally if the interceptor was created locally (analogue to the interceptor used for routing actual bean invocations.)