First, this post has nothing to do with remote INTERFACE vs local. It's about a local JBoss speaking to a remote JBoss (non-clustered setup).
The local JBoss has a JMX Bean that acts as a client and a stateless session bean, let's call it WorkerBean. The second JBoss also has WorkerBean deployed on it.
Code in the JMX decides if it need to use the local WorkerBean or the one deployed on the remote server. This code creates a context object with the provider url pointing either to localhost, or the remote JBoss' address.
My problem is, I always get the local WorkerBean, even if I explicitly ask for the remote one. If I undeploy WorkerBean from the local server, I get the remote one. So it's NOT a communication problem to the remote server as it works, as long as the bean is not deployed locally.
I am probably missing something fundamental regarding using JNDI to get hold of my beans. I do not think this is JBoss specific (though I haven't tested on another server), but rather me doing something wrong - probably JNDI wise.
I have set up a test project that I can provide, replicating this problem.
Code in JMX bean that creates the context and looks up the bean:
I don't currently use JBoss, but I think this might be app server specific. The host portions of JNDI names tend to vary by app server. I'm going to move this to JBoss. The moderators there can move it back to EJB if I am wrong.
i had the same problem,and after debugging and getting in depth for a few days (99% of the credit is to my collageus actually) this is the result:
When JBOSS (4.0.1 don't know about later versions) starts up, it turns to a class called InvokerInterceptor and sets there a local invoker(the call is static,and it comes from the LocalInvoker class). When you call for your remote bean,what actually happens is that your call goes through a chain of interceptors defined in your local JBOSS.One of them is that InvokerInterceptor fellow,and you get back a local object (look at isLocal() function in InvokerInterceptor and you figure out why right away).
You can try to workaround this behaviour by defining your own interceptors in standardjboss.xml and making JBOSS turn to them instead of build-ins,but be aware that you can get undefined behaviour in other cases if you overwrite this setting.If you do try to workaround,note the static call I mentioned in LocalInvoker (have to take care of that as well).
Our final solution is to use web services - might consider that too instead of all this mess.