directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alex Karasulu" <akaras...@apache.org>
Subject Re: [JNDI] Reorganization
Date Sat, 02 Feb 2008 07:11:41 GMT
On Jan 31, 2008 11:02 AM, Emmanuel Lecharny <elecharny@gmail.com> wrote:

> I'm just wondering if we can move around some JNDI related classes from
> core to apacheds-server-jndi ?
>

We really want to put what this is soon to become (a JNDI wrapper around the
core) into it's own module. server-jndi is a remnant of the old days when we
used to start up the server (networking and all) using a 2nd JNDI context
factory besides the core JNDI context factory.

You want to move the core JNDI provider out and make it purely a wrapper
around the core right?  So this way using server-jndi is a bit missleading.
I guess we can just create a jndi-wrapper module to wrap the core.  I don't
think we need a jndi-wrapper around the server with networking enabled -
there's no point to that anymore.


>
> The idea is to reach a point where the server is not anymore depending
> on JNDI.
>

Yep.


>
> The current architecture is the following :
>
> client <-- JNDI --> server
>

That's a pretty simple view of ApacheDS :).


>
> but this is a little but more complex, if you look inside the Client and
> the Server. First, you have two kind of clients :
> o Remote clients, using LDAP protocol to communicate with the server
> o Client embedding the server (no protocol communication, direct API
> dialog)
>

Yep.


>
> Remote clients :
> ---------------------------
>
> They are communicating with the server traversing many layers :
>
> Client
> Sun JNDI API
> LDAP procotol coder/decoder
> <--- BER encoded data are passed via socket --->
> MINA
> Ldap BER coded/decoder
> Ldap protocol handlers
> JNDI mapping
> ADS core
> Backend
>

True.


>
> Embedding client :
> --------------------------------
>
> This is much simpler :
> Client
> Sun JNDI API
> JNDI mapping
> ADS core
> Backend
>
> Now, we have two options :
> 1) we want to offer a JNDI layer on top of the server.


On top of the core only.  Let's call it a wrapper.


>
> 2) we want to offer a direct access to the server API, not passing
> through a JNDI layer
>

Right.


>
> Both options are compatible, if we consider that the server under a
> network layer is like an embedded server where the client is the Ldap
> protocol handler.
>
> So the idea is to separate the JNDI mapping from the core server, and to
> allow clients to embed either the [JNDI layer + core] stack, or simply
> the [core] stack.
>

+1


>
> Atm, all the JNDI mapping is contained into the apacheds-core
> sub-project. My question is : can we move to apacheds-server-jndi all
> the DirContext, ServerContext, LdapContext, etc classes ?
>

I'd just move it to apacheds-jndi-wrapper or even apacheds-core-jndi.  Don't
know.  But apacheds-server-jndi makes it seem like the wrapper is for the
whole server with networking and all.


>
> The main issue is that we have the current dependencies scheme :
>
> apacheds-server-jndi -> apacheds-core, apacheds-protocol-ldap
> apacheds-protocol-ldap -> apacheds-core
>

This is because server-jndi is a bad choice.  It has the ldap protocol
because it was a wrapper around the whole server with networking enabled.
It's a remnant that's been removed because of the bigbang.


>
> maybe the apacheds-server-jndi is misnamed, and should be split in two
> parts, one containing the ApacheDS class, another one containing the
> JNDI layer...
>

Yep exactly.  Where ApacheDS goes though I have no clue.  Perhaps we just
rename the server-jndi module to just server.  Then we create a jndi-wrapper
or core-jndi module just for moving these classes out of the core.

Alex

Mime
View raw message