directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel Lécharny <elecha...@gmail.com>
Subject Re: API relaxed mode
Date Thu, 30 Apr 2015 17:21:02 GMT
Le 30/04/15 18:08, Radovan Semancik a écrit :
> On 04/28/2015 01:53 PM, Emmanuel Lécharny wrote:
>> Where on OpenLDAP schema do you need a LAX mode ? AFAICT, we are able
>> to parse all the OpenLDAP schemas in Strict mode... 
>
> There seems to be plenty of issues:
> ERR_04486_VALUE_ALREADY_EXISTS The value 'preferredDeliveryMethod'
> already exists in the attribute (m-may)
> ERR_04486_VALUE_ALREADY_EXISTS The value 'streetAddress' already
> exists in the attribute (m-may)
> ERR_04486_VALUE_ALREADY_EXISTS The value 'telephoneNumber' already
> exists in the attribute (m-may)
> ERR_04486_VALUE_ALREADY_EXISTS The value 'preferredDeliveryMethod'
> already exists in the attribute (m-may)
> ERR_04317 The created MatchingRule must refers to an existing SYNTAX
> element
> ...
> ERR_04306 Cannot find a Syntax object 1.3.6.1.4.1.1466.115.121.1.42
> while building cross-references for the protocolInformation
> AttributeType.
> ERR_04308 Cannot find an Equality MatchingRule object for
> protocolInformationMatch while building cross-references for the
> protocolInformation AttributeType.
> ERR_04306 Cannot find a Syntax object 1.3.6.1.4.1.1466.115.121.1.21
> while building cross-references for the enhancedSearchGuide
> AttributeType.
> ERR_04306 Cannot find a Syntax object 1.3.6.1.4.1.1466.115.121.1.31
> while building cross-references for the matchingRuleUse AttributeType.

I think we are too strict here. The OpenLDAP schema contain duplicate AT
declaration that should be fixed (I will fill an ITS for that), but in
any case, it should not be considered as an error by the schema parser.

> ...
>
> (OpenLDAP 2.4.31)
>
> Strangely this seems to be the same in both strict and relaxed modes.
>
>> Also one clue about the whay the schemaManager processes schemas : -
>> a first pass is done where we simple read all the schema elements,
>> not controling any of the interdependence between them (for instance,
>> if an OC is declared but not the used AT, then we accept the OC). - a
>> second pass now check all the dependencies between all the schema
>> elements. So to speak, this is the STRICT mode. Does it make sense ? 
>
> Thanks. That helped a bit. I have been able to move forward by
> explicitly calling schemaManager.loadAllEnabledRelaxed() instead of
> connection.loadSchema(). And then ignoring all the errors
> (schemaManager.getErrors()). This is not very intuitive for the
> developers that try to use the API. But I can live with that.

Well, it was not intented to be exposed... It would be valuable to add a
parameter, like connection.loadSchema( boolean ), where the boolean
would be true or false, depending on teh fact we want to have a relaxed
loading or not.

>
> However, there is something that bothers me a bit more. The API won't
> survive attempts to work with such a schema. 

Yes, that is expected.

> E.g. attempt to get root DSE dies with:
>
> ERR_04269 ATTRIBUTE_TYPE for OID configcontext does not exist!

You can't expect to be able to communicate with a LDAP server for which
we don't have a correct schema, right ?
>
> After all of this I think the best option would be to resign on using
> the schema-aware mode to connect to OpenLDAP. 

I think we can make it working. It's a PITA, but t worth the effort, IMHO.

> I've tried to switch to schema-less mode by not setting any
> schemaManager to a connetion (is this the correct way?). It looks like
> this might work. At least root DSE fetch worked. I'll make more tests,
> but if it is like this then I'm quite OK with this. 
That will work, except that you won't be able to control anything client
side. Typically, comparing values will just be a huge PITA.

> I'm able to get a schema to be processed. And I'm able to execute LDAP
> commands. Even though they are schema-less that's OK for me as I need
> to convert them to ConnId (Java) data types and therefore I need to
> process the schema explicitly anyway.
>
> So, assuming that I do not run into any more problems I'm just
> thinking that documenting what I've found on the API site would be
> enough for other users to know what to do when connecting to OpenLDAP.
> I can write the documentation.
>
> Looking back it seems that my worst problem was that I haven't
> understood how schema manager and schema loader works. I have probably
> used them in a wrong way by naively calling connection.loadSchema()
> and thinking that it will work. I guess that other API users will make
> the same mistake. So I think that investing time to document this is
> really going to help.

You bet...

>
> I still know about one more problem with root DSE in 389ds. I'll
> handle that later.
>
> BTW. I've also re-run my tests with OpenDJ and API 1.0.0-M31-SNAPSHOT
> rev.1676504, schema-aware, quirks mode on. It seems to work well.
> Except the small detail that the VLV support seems to be broken in the
> latest stable OpenDJ (2.6.2) ... but that's not our problem :-)
>



Mime
View raw message