I believe there's a small logic error in org.jnp.interfaces.NamingContext which I'll attempt to demonstrate.
We have two heterogeneous partitions. While each partition is homogeneous, they are heterogeneous to each other. A service in PartitionA needs to access PartitionB. I create my InitialContext with the jnp.partitionName property set and end up getting a context on my own server. If I set the Context.PROVIDER_URL instead, I can access PartitionB.
The issue is the way the checkRef method of NamingContext works. Currently (at least in the 3.0.4 and 3.0.5RC1 releases), the method works like this:
1. If Context.PROVIDER_URL is set, attempt to get a connection using it
a) if server is null, discoverServer
2. When Context.PROVIDER_URL is null or empty, set server to localServer
b) if server is null, discoverServer
This does not allow for a server in PartitionA to get a context to a server in PartitionB without having a list of provider urls. I've changed the code like this:
< // Use server in same JVM
< naming = localServer;
-> if (refEnv.get(JNP_PARTITION_NAME) != null)
-> {
-> naming = discoverServer(refEnv);
-> }
-> if (naming == null)
-> {
-> // Use server in same JVM
-> naming = localServer;
< if (naming == null)
< {
< naming = discoverServer (refEnv);
-> if (naming == null)
-> {
-> if (refEnv.get(JNP_PARTITION_NAME) == null
)
-> {
-> naming = discoverServer (refEnv);
-> }
if (naming == null)
// Local, but no local JNDI provider found!
throw new ConfigurationException ("No valid Context.PROVIDER_URL was found");
< }
-> }
-> }
This is a little ugly, but I wanted to keep the logic for the short-circuit in place if jnp.partitionName wasn't set.
Am I correct in believing that jnp.partitionName should be respected when getting an InitialContext from within a server? If not, is there another way for us to achieve what we want without resorting to a list of provider urls?
Cheers!
Richard
