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] Updated: NamingHome
Date Fri, 18 Feb 2005 16:42:03 GMT
   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.
-
-
-
-
-
-

Mime
View raw message