On 04/30/2015 07:21 PM, Emmanuel Lécharny wrote:
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.
Well, it is worse than that. I'm past this point now, but as far as I
remember either OpenLDAP or 389ds had the same attribute in both MAY and
MUST, attributes used syntaxes that were not declared and so on. I've
tried to add all these "quirks" to the relaxed mode. But it ended up
like this:
https://github.com/Evolveum/directory-shared/commit/b941ff690a41cd03b31679759dcf2fb367b1cb83
In retrospect I don't think that fully schema-aware client will work
well with OpenLDAP or 389ds.
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.
I was thinking more along the lines of this:
DefaultSchemaManager schemaManager = new DefaultSchemaManager(schemaLoader);
schemaManager.setRelaxed();
connection.loadSchema(schemaManager);
I think that's cleaner, extensible and much more readable. What do you
think?
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.
That's OK for me. I'm buildig an identity connector so I'm converting
data from LDAP data model to ConnId data model. So I need to check
types, convert and compare values anyway.
Actually I've already modified my connector. It was easy.
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...
OK. So I take the task to document this. But I would like to have a
working code first so I'm sure the documentation that I write does not
lie :-)
--
Radovan Semancik
Software Architect
evolveum.com
