directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel Lecharny <elecha...@gmail.com>
Subject JNDI vs protocol vs Core API
Date Fri, 26 Sep 2008 18:01:35 GMT
Hi guys,

as i'm struggling with referrals for days now, I just discovered that 
there are many places in the server which are not handling them 
correctly. Atm, the only part which is sane is the protocol layer. For 
embedded servers, not passing through the protocol layer, I have to say 
that the referrals are simply ignored.

Here are the problem we have.

A bit of history. Before we removed JNDI from the server, here was the 
chain followed by an incoming request :

1) through the network
client --> JNDI--> {network}--> ASN.1codec --> Protocol handler --> JNDI 
--> NexusProxy --> Interceptors --> ...

2) embedded
client --> JNDI--> NexusProxy --> Interceptors --> ...

Simple, clear, but messy inside the server.

We decided to remove JNDI from the server, to offer our own API 
(CoreSession) on top of which we were supposed to rewrite the JNDI 
layer. here is what are suposed to have now :
1) through the network
client --> JNDI--> {network}--> ASN.1codec --> Protocol handler --> 
CoreSession --> OperationManager --> Interceptors ...

2) embedded with JNDI
client --> JNDI--> CoreSession --> OperationManager --> Interceptors ...

3) embedded without JNDI
client --> CoreSession --> OperationManager --> Interceptors ...

As everyone can see, the JNDI provider is just offered as a thin layer 
to the users who don't want to deal with ADS inside out. This is perfect 
for those who want to migrate from version X to version Y. But they can 
also use the better API whoch does not use the cursed semantic of JNDI.

So far, so good.

Now, the problem is that for referrals, as we have also removed the 
ReferralInterceptor from the core server (a very good move, when you 
take the time to think about it - and it took me two hours of discussion 
with Alex to get it -), you have a new problem : where do we have to 
handle referrals ?

The first idea was to move it to the protocol layer. So be it. But the 
problem is that the JNDI referral handling was not anymore done (and as 
a consequence, the associated tests were disabled, until the JNDI 
provider was fixed to handle those referrals).

I'm currently re-implementing the Referral handling in this JNDI layer, 
but I suddenly discovered that this was not a good idea *at all*. And so 
was the initial idea to implement the referrals handling into the 
protocol layer. We now have 3 places where we must implement this process :
- in the protocol layer
- in the JNDI provider
- and in the CoreSession layer.

Bad...

So here is what I suggest : we should handle referrals into the 
CoreSession layer, and deal with the thrown exceptions 
(LdapReferralExceptio, LdapPartialResultException, etc) into the JNDI 
and protocol layer, otherwise, we will do the job three times (and it's 
not a funny job ...)

thoughts ?

PS: don't be too picky with the names I'm using (like CoreSession is not 
really the API we have built), but I'm sure that Alex can correct me. I 
think however that the general picture is ok.


Thanks !

-- 
--
cordialement, regards,
Emmanuel L├ęcharny
www.iktek.com
directory.apache.org



Mime
View raw message