On Jan 31, 2008 11:02 AM, Emmanuel Lecharny <[EMAIL PROTECTED]> 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
