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 <[email protected]> writes: > Le 7/26/13 12:01 AM, Richard Sand a écrit : >> 5) What needs to happen to have the results of calls to >> LdapConnection.search(..) 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: con.loadSchema() ((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 directory. It takes about 2 seconds load and is only associated with that one connection. · 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: [email protected] JID: [email protected] GPG: 0xFA8CD6D5 21D9 B2E8 7FE7 F19E 5F7D 4D0C 3FA0 810F FA8C D6D5
pgpt09l1XVbWT.pgp
Description: PGP signature
