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 Mon, 24 Jan 2005 02:06:10 GMT
   Date: 2005-01-23T18:06:10
   Editor: PhilSteitz
   Wiki: Apache Directory Project Wiki
   Page: NamingHome
   URL: http://wiki.apache.org/directory/NamingHome

   no comment

Change Log:

------------------------------------------------------------------------------
@@ -12,13 +12,13 @@
 
 = 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.
+ *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.
  *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. 
+ *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 will continue to
be supported so tomcat's global naming resources links will continue to work. 
 
 == Examples ==
 

Mime
View raw message