directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Phil Steitz <>
Subject Re: Integrating naming
Date Sat, 01 Jan 2005 00:15:00 GMT
That is a very interesting idea. The in-memory JNDI provider is 
augmented with a proxy or meta-directory-like federation capability. 
This could be used on the server side for containers or other 
applications that want to be able to configure either local, in-memory 
or remote JNDI services for different namespaces or on the client side 
for apps that want to federate JNDI namespaces.

IIUC, to make it work, we need a way to represent the context forwarding 
(like what you have below) and a facility for handling the delegation. 
Both of these will be tricky.  For the first thing, I think something 
like this would be more natural:

<context name=foo>
   <context-ref name="bar" target="jndi:path/to/context">

Then the rest could work like the XmlConfigurator in naming does now.  A 
reference to "foo/bar/some/other/path" would get delegated to the 
"remote" context as a request for /some/other/path.

The more I think about it, though, the more I think it would be better 
to have a separate config for the forwarding by itself, though.  This is 
partly because containers are going to want to use their own context 
initialization config, which is largely determined by specs in the case 
of J2EE.  The current XmlConfigurator setup is really just a substitute 
for the environmnent config and object factories that containers provide.

So, the context forwarding would just consist of a bunch of
<context name="foo" target="jndi:/path/to/context"/> elements.

Getting the delegation to actually work will be very interesting.  The 
in-memory provider could build the "jndi:" namespace based on the 
config, but what exactly it maintains in the references, and how the 
(federating) context implementation uses these references when resolving 
names is not obvious.

Like I said, a very interesting idea.  I will add this to the "roadmap" 
page that I am putting together for [naming].


Noel J. Bergman wrote:
> The naming package is a standalone, embedded service provider that provides
> an in-memory context.  It shares common JNDI issues such as parsing, Object
> and State factories, etc., but it does not currently have a strong runtime
> link to the rest of our architecture.  This is a proposal to change that via
> a quite simple and useful route.
> I propose that we look at naming as the visible piece that is embedded, with
> persistent contexts registered with naming.  Namespace Federation would take
> care of the rest.
> An off-the-cuff approach is:
>   <resource name="foo" type="java.naming.DirContext">
>     <parameter>
>       <name>context</name>
>       <value>location in persistent DIT</value>
>     </parameter>
>   </resource>
> So when I refer to foo in my local context, name space federation takes me
> through to the baseURL, which is in the directory server.  This would work
> nicely in embedded and remote modes of operation, would isolate application
> code from actually knowing which was used, and leverage all of the other
> features of naming.
> Further examples:
>   <!-- context in local JNDI server -->
>   <resource name="mycontext" type="java.naming.DirContext">
>     <parameter>
>       <name>context</name>
>       <value>jndi:path/to/context</value>
>     </parameter>
>   </resource>
>   <!-- context in remote LDAP server -->
>   <resource name="groups" type="java.naming.DirContext">
>     <parameter>
>       <name>context</name>
>       <value>ldap://ldap.mydomain.tld/ou=groups,dc=mydomain,dc=tld</value>
>     </parameter>
>   </resource>
> Thoughts?
> 	--- Noel

View raw message