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 ==
