On Wed, Aug 21, 2013 at 5:37 AM, Gerald Turner <gtur...@unzane.com> wrote:
> 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 <elecha...@gmail.com> 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: > > what was the error encountered while using above schema loaders? (are using a then inside a web application?) > ((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? > > no, not at the moment, can you file a request for this in JIRA[1] > · 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). > > yes, SchemaManager can be safely reused > · 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. > > Studio already has the capability to parse this type of schema, perhaps we just need to move it to a utility class, another request please > · 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! > > it would be helpful if you can attach the stacktrace to a new bug report > · 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. > > personally I use the JarLdifSchemaLoader in cases like these Let us know if you have any issues with this schema loader in your application environment [1] https://issues.apache.org/jira/browse/DIRAPI > -- > Gerald Turner Email: gtur...@unzane.com JID: gtur...@unzane.com > GPG: 0xFA8CD6D5 21D9 B2E8 7FE7 F19E 5F7D 4D0C 3FA0 810F FA8C D6D5 > -- Kiran Ayyagari http://keydap.com
