Hi
I've sort of solved this issue, and these are my findings:
1. To register a reference to an ejb that is running a different appserver:
add an external resource with the following properties:
jdni name : myRemoteBean [this name will appear in the local jndi]
resource type : javax.naming.Reference
factory class : com.sun.enterprise.naming.SerialInitContextFactory
jndi lookup : services.orbit.client.FISCHRHRemote [name of the bean in the remote jndi]
properties:
org.omg.CORBA.ORBInitialHost=remotehostname
org.omg.CORBA.ORBInitialPort=3700
The key is the 2 properties that specifies the remote host. I thought of using the com.sun.appserv.iiop.endpoints property to try to convince glassfish to loadbalance when I use the remote jndi name, but this leads to a java.io.NotSerializableException.
The other key thing is that there appears to be a bug in the admin console that causes it not pass through all the properties I specified. If I use the commandline to register the external jndi resource it works fine. Check out the bug I logged here :
https://glassfish.dev.java.net/issues/show_bug.cgi?id=5009
To use this you can just use a normal lookup against your local jdni:
FISCHRH scheme = (FISCHRH)ctx.lookup("myRemoteBean");
2. To register a context from different appserver in my local context:
The setup is the same as before except that resource type becomes "javax.naming.Context" and obviously the jndi lookup property needs to point to the context on the remote appserver.
Using is this is a bit tricky though. If you want to lookup an reference inside the context in the remote machine and you try to do this:
Object obj = initialCtx.lookup("services/recon/ReconServicesRemote");
it will break with a NameAlreadyBoundException. (services is the name of the context I registered, it's also called services on the remote jndi). IMHO this is a bug.
If you first lookup the context, then the object, it works, eg:
Object obj = initialCtx.lookup("services");
Context ctx2 = (Context)obj;
Object obj2 = ctx2.lookup("recon/ReconServicesRemote");
I found one case that did not work, that was when I tried to lookup a jdbc connection in a remote jndi registered as I described above. The appserver resolves the name of the pool that the jndi name links to and then tries to find that pool on the local appserver. This also seems like a bug.
All in all I got it working, but it's not giving me a warm fuzzy feeling. It seems that the appserver does not keep the jndi contexts separate, they keep interfering with one another.
Cheers
Eduard
[Message sent by forum member 'eduardp' (eduardp)]
http://forums.java.net/jive/thread.jspa?messageID=274226