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