You need to use a separate InitialContext with a distinct set of naming environment properties for each cluster. Even if autodiscovery could be configured to discover both clusters, the downloaded naming proxy would come from one or the other and would only be able to connect to servers in that cluster.
Why are you trying to auto-discover two clusters? Is this really a sign that for this particular application you should have a single partition? (You can deploy more than one partition on an AS, so all servers could be part of a single partition for this application, while maintaining separate partitions for whatever else you're doing that led you to create 2 clusters.)
Thanks Brian. I understand your comment and I agree with it.
How does a client look up two different EJB applications deployed on two different clusters?
Can jndi.properties work in this case? In this case, I do understand that the proxy downloaded will be from one of the clusters.
Do I load the naming environment for each cluster one at a time?
To look up two different EJB applications deployed on two different clusters, the client will need to create more than one InitialContext.
The contents of jndi.properties will be combined with whatever other properties you
pass in via a call to new InitialContext(Hashtable<?,?> environment). So I would recommend you create a utility class with methods to create an appropriate "Hashtable<?,?> environment", one for each cluster. The returned Hashtable would include the cluster-specific environment properties; any properties that are common could come from jndi.properties.
How you populate each cluster specific Hashtable is up to you, but I'd recommend externalizing the information in properties files, e.g. clusterA.properties and clusterB.properties.