How to use HA-JNDI from a client running inside a cluster

This document does not refer to accessing HA-JNDI from remote client applications, but from within a cluster.

The JBoss documentation specifies:

"If you want to access HA-JNDI from the server side, you must explicitly get an InitialContext by passing in JNDI properties. The following code shows how to access HA-JNDI.

Properties p = new Properties();
p.put(Context.INITIAL_CONTEXT_FACTORY, "org.jnp.interfaces.NamingContextFactory");
p.put(Context.URL_PKG_PREFIXES, "jboss.naming:org.jnp.interfaces");
p.put(Context.PROVIDER_URL, "localhost:1100"); // HA-JNDI port.
return new InitialContext(p); 

The Context.PROVIDER_URL property points to the HA-JNDI service configured in the HANamingService MBean (see Section 16.2.3, &147;JBoss configuration&148;)."

However, this does not work in all cases, especially when running a multihomed cluster (several JBoss instances on one machine bound to different IPs). A safer method is not to specify the Context.PROVIDER_URL (which does not work in all scenarios) but the partition name property:

Properties p = new Properties();
p.put(Context.INITIAL_CONTEXT_FACTORY, "org.jnp.interfaces.NamingContextFactory");
p.put(Context.URL_PKG_PREFIXES, "jboss.naming:org.jnp.interfaces");
p.put("jnp.partitionName", "DefaultPartition"); // partition name.
return new InitialContext(p); 

Accessing HA-JNDI Resources from EJBs and WARs -- Environment Naming Context

If your HA-JNDI client is an EJB or servlet, the least intrusive way to configure the lookup of resources is to bind the resources to the environment naming context of the bean or webapp performing the lookup.  The binding can then be configured to use HA-JNDI instead of a local mapping.  Following is an example of doing this for a JMS connection factory and queue (the most common use case for this kind of thing.

Within the bean definition in the ejb-jar.xml or in the war's web.xml you will need to define two resource-ref mappings, one for the connection factory and one for the destination.

  <resource-ref>
    <res-ref-name>jms/ConnectionFactory</res-ref-name>
    <res-type>javax.jms.QueueConnectionFactory</res-type>
    <res-auth>Container</res-auth>
  </resource-ref>

  <resource-ref>
    <res-ref-name>jms/Queue</res-ref-name>
    <res-type>javax.jms.Queue</res-type>
    <res-auth>Container</res-auth>
  </resource-ref>

Using these examples the bean performing the lookup can obtain the connection factory by looking up 'java:comp/env/jms/ConnectionFactory' and can obtain the queue by looking up 'java:comp/env/jms/Queue'.

Within the JBoss-specific deployment descriptor (jboss.xml for EJBs, jboss-web.xml for a WAR) these references need to mapped to a URL that makes use of HA-JNDI.

  <resource-ref>
    <res-ref-name>jms/ConnectionFactory</res-ref-name>
    <jndi-name>jnp://localhost:1100/ConnectionFactory</jndi-name>
  </resource-ref>

  <resource-ref>
    <res-ref-name>jms/Queue</res-ref-name>
    <jndi-name>jnp://localhost:1100/queue/A</jndi-name>
  </resource-ref>

The URL should be the URL to the HA-JNDI server running on the same node as the bean; if the bean is available the local HA-JNDI server should also be available.  The lookup will then automatically query all of the nodes in the cluster to identify which node has the JMS resources available.

Why do a need to do this programmatically? Why can't I just put this in a jndi.properties file?

The app server's internal naming environment is controlled by the

conf/jndi.properties

file, which should not be edited.

No other jndi.properties file should be deployed inside the app server because of the possibility of its being found on the classpath when it shouldn't and thus disrupting the internal operation of the server. For example, if an EJB deployment included a jndi.properties configured for HA-JNDI, when the server binds the EJB proxies into JNDI it will likely bind them into the replicated HA-JNDI tree and not into the local JNDI tree where they belong.

How can I tell if things are being bound into HA-JNDI that shouldn't be?

Go into the the jmx-console and execute the

list

operation on the

jboss:service=JNDIView

mbean. Toward the bottom of the result the contents of the "HA-JNDI Namespace" are listed.  Typically this will be empty; if any of your own deployments are shown there and you didn't explicitly bind them there, there's probably an improper jndi.properties file on the classpath. See this forum thread for an example.

Referenced by: