directory-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From directory-...@incubator.apache.org
Subject [Apache Directory Project Wiki] New: NamingHome
Date Sun, 23 Jan 2005 23:15:01 GMT
   Date: 2005-01-23T15:15:01
   Editor: PhilSteitz
   Wiki: Apache Directory Project Wiki
   Page: NamingHome
   URL: http://wiki.apache.org/directory/NamingHome

   no comment

New Page:

= Current state =
The current code is focussed on supporting the java:comp/env namespace for web applications
running inside a container. The Selector``Context and Context``Bindings 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 Context``Bindings class maintains hashtables linking external names with Naming``Context
instances, as well as threads and classloaders. 
 *The javaURL``Context``Factory implements get``Initial``Context as follows: Check to see
if the current thread or classloader is bound.  If so, return a new Selector``Context; otherwise
return a shared, writable Naming``Context maintained in a static member.
 *The Selector``Context locates bound contexts and delegates JNDI operations to them. It uses
its getBoundContext method to retrieve the appropriate context from Context``Bindings.  If
the Selector``Context is created as an initial context and get``Bound``Context does not find
a context bound to the calling thread/classloader, it creates a new Naming``Context and binds
the caller to it.

= XML Configurator =
The Xml``Configurator 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 javaURL``Context``Factory is used by the Xml``Configurator, 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 Xml``Configurator to support (multiple) named contexts and modify Naming``Context``Factory
and javaURL``Context``Factory to look for context names in the environment and either create
new named contexts with these names or return the named context from Context``Bindings.  For
backward compatibility, map the empty name to a shared, writable context rooted at "java:comp/env."
 *Add a "base" element to the context element to play the role that the name element 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.
 *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 Naming``Context does now, but with the name of the other context included in env. 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 Xml``Configurator 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 Context``Bindings 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 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>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");}}}

=== Multiple in-memory contexts, with links ===
{{{<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(NamingContext.NAME, "app1");
Context ctx = new InitialContext(env);
Context env = (Context) ctx.lookup("java:comp/env);
Integer port = (Integer) env.lookup("port");
DataSource ds = (DataSource) env.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");}}}

More challenging would be to support

{{{Integer port = (Integer) env.lookup("config/port");}}} 

without creating the link explicitly.  This would require that the Name``Parser become aware
of the links, as opposed to inserting them statically.







Mime
View raw message