Hi,
I'm just wondering if we can move around some JNDI related classes from
core to apacheds-server-jndi ?
The idea is to reach a point where the server is not anymore depending
on JNDI.
The current architecture is the following :
client <-- JNDI --> server
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)
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
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.
2) we want to offer a direct access to the server API, not passing
through a JNDI layer
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.
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 ?
The main issue is that we have the current dependencies scheme :
apacheds-server-jndi -> apacheds-core, apacheds-protocol-ldap
apacheds-protocol-ldap -> apacheds-core
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...
wdyt ?
--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org
