directory-api mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gerald Turner <>
Subject Re: API behavior questions
Date Wed, 21 Aug 2013 00:07:40 GMT
Hello, I've been working with the client API for the past week and have
a few questions related to schema loading.

Emmanuel Lécharny <> writes:
> Le 7/26/13 12:01 AM, Richard Sand a écrit :
>> 5) What needs to happen to have the results of calls to
>> return entries for which isSchemaAware is
>> true?
> The LdapConnection must be schema aware itself.
> For that to happen, you just have to call the loadSchema() method :
> LdapConnection connection = new LdapNetworkConnection( "localhost", 389 );
> connection.loadSchema();
> Here, we will load the default schemas.
> You can use some specific schema by using :
> connection.loadSchema();
> connection.addSchema( "MySchema.schema" );
> where the "MySchema.schema" is a schema in OpenLDAP format.
> You can also use a SchemaLoader, but this get a bit too complex atm
> (and sadly, the associated method is not yet in the LdapConnection
> interface)

I've tried:

  ((LdapNetworkConnection) con).loadSchema(new DefaultSchemaLoader(…))
  ((LdapNetworkConnection) con).loadSchema(new SingleLdifSchemaLoader(…))
  ((LdapNetworkConnection) con).loadSchema(new JarLdifSchemaLoader(…))

without much success until finally trying:

  ((LdapNetworkConnection) con).loadSchema(new LdifSchemaLoader(…))

with a File pointing at a modified local copy of the ApacheDS schema

It takes about 2 seconds load and is only associated with that one

· Are there other interfaces that can be used to only load the
SchemaManager _once_ and have it shared across connections?

· Can I safely use the SchemaManager after a connection has been
returned to the pool.  (e.g. instantiating Dn and other objects that
take SchemaManager in their constructors - at a point in the application
where communication with the LDAP server is no longer necessary - doing
comparisons on data structures that have been cached in a session).

· I see a comment in DefaultSchemaLoader constructor: “TODO Handle
schema loading on other LDAP servers” — how difficult would it be to
implement parsing of OpenLDAP cn=schema,cn=config?  If it's just a
matter of banging strings around because core parsing already exists,
maybe I could have a go at it.

· Various times while parsing schemas (particularly while playing with
SchemaToLdif), I got rather ambiguous ParserExceptions.  In a debugger I
could trace the exception to a rather detailed ANTLR exception,
unfortunately these root causes are being discarded.  Suggestion: Please
chain exceptions!

· I feel like I'm going down a rabbit hole - all I really needed was to
get case-insensitive equality on Dn comparison.  Our server arbitrarily
returns “o=People” and sometimes “o=people”.  Making the LDAP Client API
schema aware solves this, but so would hacking in toLowerCase in a
bazillion places.  Maybe implementing a dumbed down SchemaManager that
returned some very naïve and static set of assumptions for common
attributes like ‘o’, ‘ou’, ‘cn’, and ‘dc’ would work.

Gerald Turner   Email:   JID:
GPG: 0xFA8CD6D5  21D9 B2E8 7FE7 F19E 5F7D  4D0C 3FA0 810F FA8C D6D5

View raw message