directory-users 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 04:38:00 GMT
On Wed, Aug 21, 2013 at 5:37 AM, Gerald Turner <gturner@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 <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?)

>   ((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: 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