[Apache Directory Project Wiki] Updated: NamingHome

[di...@incubator.apache.org]

   Date: 2005-02-18T08:42:03
   Editor: PhilSteitz
   Wiki: Apache Directory Project Wiki
   Page: NamingHome
   URL: http://wiki.apache.org/directory/NamingHome

   Introduce jndi urls

Change Log:

------------------------------------------------------------------------------
@@ -11,9 +11,10 @@
 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" 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.
- *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.
+ *Extend the Xml``Configurator to support (multiple) named contexts and modify Naming``Context``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." - 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 Context``Bindings.  To do this, add a jndi``URLContext``Factory sourcing Selector``JNDIContext instances, where Selector``JNDIContext extends and works like Selector``Context, but overrides get``Bound``Context to locate the bound context by name, rather than calling thread or classloader.  
+ *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 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:
@@ -103,15 +104,3 @@
 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.
-
-
-
-
-
-