directory-api mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gerald Turner <gtur...@unzane.com>
Subject Re: API behavior questions
Date Wed, 21 Aug 2013 18:37:22 GMT
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.

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

-- 
Gerald Turner   Email: gturner@unzane.com   JID: gturner@unzane.com
GPG: 0xFA8CD6D5  21D9 B2E8 7FE7 F19E 5F7D  4D0C 3FA0 810F FA8C D6D5

Mime
View raw message