directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel Lecharny <>
Subject Re: [LDAP] Merging server-ssl with protocol-ldap
Date Fri, 09 Mar 2007 22:01:50 GMT
Enrique Rodriguez a écrit :

> Any objections to my merging server-ssl with protocol-ldap?

Hmmm... Not so sure that would be a good idea (see further), but my 
rationals may be wrong...

> server-ssl only has 2 classes in it and it is setting up a really
> problematic cyclic dependency with core-unit, server-unit, and
> server-jndi.  

I think that the cyclic dependency can be solved if we modify the 
LdapsITest class : it uses Attribute(s)Impl when it should use 
BasicAttribute(s) instead.

> We never noticed the cycle before because the SslFilter
> was class-loaded using reflection and when I use normal construction
> m2 flags it and ceases to build.  The only reason I could see to have
> server-ssl separate was, again, the JDK 1.5+ issue, which is gone now.
> I would do this in the SASL branch.  I think it makes sense to deal
> with more tightly integrating SSL at the same time as SASL, since it's
> all part of a cohesive LDAP protocol impl.

Yeah, but the point is that it would also be cool to separate SSL 
handling from Ldap protocol., IMHO. For SASL, that's a totally different 
story, but anyway, a server-sasl could also be a good idea, because we 
never know if another mechanism may be invented or added.

May be we can further the convo a mittle bit, because beside the SASL 
basic handling, we might want to offer a easy way to implement new 
mechanisms without having to modify the whole server, or delivering a 
new version. I'm thinking about storing the mechanism impelmentation 
either as plugins, or as Java classes compiled and stored into ADS 
itself (of course, this will have a huge implication ...).

> Enrique

FYI, while I was looking for partition implementation, I had to dive 
into the initialization part of the server, then to the Authenticator 
part, and I started to read what you wrote about SASL and TLS. It would 
be good if we can cross-polinate our work on those subjects (even if I 
don't know a lot about SASL ;)


View raw message