0.8 Setup

The 0.8 code is focussed on supporting the java:comp/env namespace for web applications running inside a container. The SelectorContext and ContextBindings classes enable multiple different naming contexts to be set up and bound to threads and classloaders. In tomcat, where the code originated, JNDI resources can be configured "globally" or at the web app level. Global naming resources are made available to individual web apps via resource links.

Some details

  • The ContextBindings class maintains hashtables linking external names with NamingContext instances, as well as threads and classloaders.
  • The javaURLContextFactory implements getInitialContext as follows: Check to see if the current thread or classloader is bound. If so, return a new SelectorContext; otherwise return a shared, writable NamingContext maintained in a static member.
  • The SelectorContext locates bound contexts and delegates JNDI operations to them. It uses its getBoundContext method to retrieve the appropriate context from ContextBindings. If the SelectorContext is created as an initial context and getBoundContext does not find a context bound to the calling thread/classloader, it creates a new NamingContext and binds the caller to it.

XML Configurator

The XmlConfigurator was introduced to enable applications running outside of a J2EE container to load resource references and environment properties into a JNDI context. The current setup loads just one "unbound" context, rooted by default at "java:comp/env." Users can initialize contexts with different roots by supplying a value for the name attribute of the context element in the config file. The javaURLContextFactory is used by the XmlConfigurator, so by default it creates a shared, global, writable context.
A basic use case is to allow code that makes use of tomcat-managed JNDI to run outside of tomcat. Modifying the configurator dtd and initialization to support global resources and resource links will do this, but only for a single "global" context, which makes the whole concept less meaningful.

Proposal to clean up the current setup and to support federation and links across contexts

  • Extend the XmlConfigurator to support (multiple) named contexts and modify NamingContext to look for context names in the environment and either create new named contexts with these names or return the named context from ContextBindings. For backward compatibility, map the empty name to a shared, writable context rooted at "java:comp/env." - COMPLETED
  • Add a "base" attribute to the context element to play the role that the name attribute is now playing – i.e., to specify the root name relative to which all of the child entries are named. I see no need for nested context elements, since subcontexts are created implicitly based on the names of context child elements. - COMPLETED
  • Add support for "jndi urls" – i.e., urls of the form "jndi:global/config/host" or even "jndi:app1/java:comp/env", where the first component of the name following the "jndi:" scheme identifier is the name of a named context. So, "jndi:global/config/host" refers to the entry named by "config/host" in the context named "global" in ContextBindings. To do this, add a jndiURLContextFactory sourcing SelectorJNDIContext instances, where SelectorJNDIContext extends and works like SelectorContext, but overrides getBoundContext to locate the bound context by name, rather than calling thread or classloader. - COMPLETED
  • Per Roland's suggestion, add a "link" context child element which will insert a link to another named context, with links resolved using 
    new InitialContext(env)).lookup(link)
    as NamingContext does now, but with the name of the other context embedded in the link, as a jndi URL. Then "global naming resources" can be made available using a context named "global" or "root" or whatever the user likes.
  • Also per Roland's suggestion, either create a server.xml + web.xml -> naming config converter or support these config formats directly.

Then to support federation:

  • Allow urls as "base" names in XmlConfigurator context elements and add a "factory" attribute to allow the context factory to be specified/overridden. Then contexts backed by directory servers can be named and accessed via ContextBindings as above and links can be inserted in in-memory contexts to enable federation between in-memory and ldap-backed naming contexts. Note that this will work for contexts set up using the apis directly, as long as they include the names of external contexts in links. The implicit names used by tomcat will continue to be supported so tomcat's global naming resources links will continue to work.

Examples

Single, global in-memory namespace, rooted at "java:comp/env." No difference from current config or behavior 

<naming>
  <context>
    <environment name="config/host" value="www.apache.org" type="java.lang.String" />
    <resource name="jdbc/pool" type="javax.sql.DataSource">
      <parameter>
        <name>factory</name>
        <value>org.apache.commons.dbcp.BasicDataSourceFactory</value>
      </parameter>
      <parameter>
        <name>driverClassName</name>
        <value>org.hsqldb.jdbcDriver</value>
      </parameter>
      <parameter>
        <name>url</name>
        <value>jdbc:hsqldb:target/hsqldb</value>
      </parameter>
      <parameter>
        <name>username</name>
        <value>sa</value>
      </parameter>
      <parameter>
        <name>password</name>
        <value></value>
      </parameter>
    </resource>
  </context>
</naming>

Context ctx = new InitialContext();
Context env = (Context) ctx.lookup("java:comp/env);
String host = (String) env.lookup("config/host");
DataSource ds = (DataSource) env.lookup("jdbc/pool");

<naming>
  <context name="global">
    <resource name="jdbc/pool" type="javax.sql.DataSource">
      <parameter>
        <name>driverClassName</name>
        <value>org.hsqldb.jdbcDriver</value>
      </parameter>
      <parameter>
        <name>url</name>
        <value>jdbc:hsqldb:target/hsqldb</value>
      </parameter>
      <parameter>
        <name>username</name>
        <value>sa</value>
      </parameter>
      <parameter>
        <name>password</name>
        <value></value>
      </parameter>
    </resource>
  </context>
  <context name="app1" base="java:comp/env">
    <environment name="port" value="5555" type="java.lang.Integer" />
    <link name="datasource" context="global" rname="jdbc/pool" />
  </context> 
</naming>

Hashtable env = new Hashtable();
env.put(NamingContextFactory.NAME, "app1");
Context ctx = new InitialContext(env);
Context envCtx = (Context) ctx.lookup("java:comp/env");
Integer port = (Integer) envCtx.lookup("port");
DataSource ds = (DataSource) envCtx.lookup("datasource");  //follows link

Links to remote ldap-backed context inserted into default global in-memory context 

<naming>
  <context name="persistent" url="ldap://ldap.foo.com:389" />
  <context>
     ...
    <link name="config/host" context="persistent" rname="config/host" />
    <link name="config" context="persistent" rname="config" />
  </context> 
</naming>

Context ctx = new InitialContext();
Context env = (Context) ctx.lookup("java:comp/env);
String host = (String) env.lookup("config/host");

or even

DirContext dirContext = (DirContext) ctx.lookup("config");
  • No labels