my 2c ... :-)
The JXplorer LDAP client has been using JNDI since 1999, and it
hasn't been an entirely pleasant experience. As Marc and others have
pointed out, JNDI uses a complex federation architecture combined
with confusing terminology that makes it difficult to use for 'simple
ldap operations (tm)'. JXplorer solved the problem by building a
simplifying abstraction layer on top of JNDI, which also allowed for
various JNDI bugs to be fixed in a single place.
However JNDI has come a long way in the last six years, and I don't
think there are any serious bugs in the core code any more. Where it
tends to be a bit dodgy is in the leading edge stuff: DSML, ldap
controls and so on - but they improve with time, and they're actively
developed by the Sun folks.
We have a simple JNDI provider for DSML that ships with JX and can be
used stand alone, and it is easy to do similar things with other
protocols (e.g. SPML), so the JNDI architecture does work, even if it
is ornate.
JXplorer is built to allow different providers however - so if Apache
DS decided to use a 'straight LDAP' library, we could rejig JX to use
that as well, which could be neat, and would probably improve
performance a fair bit.
However, don't underestimate the amount of guff that is in the
current JNDI implementation... there's a bunch of work in there, and
I'm not sure the other LDAP implementations have all the bells and
whistles that JNDI does (they might - I honestly don't know :-) ).
So in summary: JNDI works, is a bit slow and complex, includes a
bunch of security stuff, and ships standard with Java. Other things
may be faster and simpler, but may not be as complete...
cheers,
Chris
- Re: Client library Chris Betts
-
