directory-api mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kiran Ayyagari <kayyag...@apache.org>
Subject Re: API behavior questions
Date Wed, 21 Aug 2013 18:53:21 GMT
On Thu, Aug 22, 2013 at 12:07 AM, Gerald Turner <gturner@unzane.com> wrote:

> Kiran Ayyagari <kayyagari@apache.org> writes:
> > On Wed, Aug 21, 2013 at 5:37 AM, Gerald Turner <gturner@unzane.com>
> wrote:
> >> Emmanuel Lécharny <elecharny@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?)
>
> 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: gturner@unzane.com   JID: gturner@unzane.com
> GPG: 0xFA8CD6D5  21D9 B2E8 7FE7 F19E 5F7D  4D0C 3FA0 810F FA8C D6D5
>



-- 
Kiran Ayyagari
http://keydap.com

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message