On Thu, Aug 22, 2013 at 12:07 AM, Gerald Turner <[email protected]> wrote:
> Kiran Ayyagari <[email protected]> writes: > > On Wed, Aug 21, 2013 at 5:37 AM, Gerald Turner <[email protected]> > wrote: > >> 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: > > > > what was the error encountered while using above schema loaders? (are > > using a then inside a web application?) > > The errors were really just learning exercises ;-) > > Mostly from JUnit in Eclipse, but eventually in a web application on > JBoss 7. It is odd that JarLdifSchemaLoader couldn't find the schema > directory in api-ldap-schema-data-1.0.0-M20.jar, I'll investigate this > further. > > this is most likely due to an issue with classloaders > >> ((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] > > DIRAPI-153 > > >> · 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 > > Great! > > >> · 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 > > DIRAPI-154 > > >> · 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 > > DIRAPI-155 > > >> · 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 > > I'll give this a try, thanks! > > thanks for the bug reports > -- > Gerald Turner Email: [email protected] JID: [email protected] > GPG: 0xFA8CD6D5 21D9 B2E8 7FE7 F19E 5F7D 4D0C 3FA0 810F FA8C D6D5 > -- Kiran Ayyagari http://keydap.com
