From: Emmanuel Lécharny <[email protected]> Reply: Apache Directory Developers List <[email protected]>> Date: 14 Jul 2015 at 11:39:13 To: [email protected] <[email protected]>> Subject: Re: 389 Directory Server support in API
Le 14/07/15 10:49, Radovan Semancik a écrit : > Hi, > > In rev.1690876 I've committed a couple of changes to support 389ds in > API. > > Firstly is looks like 389ds does not respond to base search of root > DSE unless the attributes are specified explicitly (* or + does not > work). So I've added support for this. Good to know. 389ds is known to be a crappy LDAP server, this is one more proof... Actually, it is compliant with the LDAP RFC. The attributes in the root DSE are operational, thus must be requested explicitly. ‘*’ only applies to regular attributes. ‘+’ is defined in an extension RFC (3673) but not part of the LDAPv3 standards series (RFC4510). > > Secondly, 389ds seems to use a lot of non-numeric OIDs. What do you mean ? Things like mixed prefix and OIDs ? This is inherited from Netscape and lazy use of proper OIDs for schema. ( myattr-oid NAME ‘myattr’ … Netscape directory and Sun DS did not enforce schema checking. Expect a lot of crap when reading and parsing schemas. Ludo > As far as I understand this should be accepted in relaxed mode of > SchemaManager. But anyway, this threw error in > SchemaEntityFactory.getOid(...) method as this one did not know that > we are in relaxed mode. The cleanest solution I could figure out is to > pull the methods isStrict() and isRelaxed() to SchemaManager > interface. It looks like this does not break anything in the ApacheDS > code. I'm still quite new to the project and I'm not sure what exactly > was the SchemaManager interface supposed to expose. Therefore can > someone please have a look and review my changes? WIll do. Thanks for dealing with all those external LDAP server s!
