The general rule around standard support is “be flexible in what you accept, strict about what you produce”. This should apply to the LDAP APIs as well.
My 2 cents, Ludo -- Ludovic Poitou http://ludopoitou.com From: Pierre Smits <[email protected]> Reply: Apache Directory Developers List <[email protected]>> Date: 14 Jul 2015 at 12:12:16 To: Apache Directory Developers List <[email protected]>> Subject: Re: 389 Directory Server support in API Hi all, <quote>And a good LDAP API should support even bad servers</quote> Is that an achievable goal? Crappy servers pose so many exceptions to the rule, that any project, trying to realise a client solution, will eventually find that has shot itself in the foot. Of course, no one can argue with a contributor scratching his own itch. But shouldn't this be done in a separate dev branch, so that trunk isn't affected until such an integration is tried, tested and accepted? Best regards, Pierre Smits ORRTIZ.COM Services & Solutions for Cloud- Based Manufacturing, Professional Services and Retail & Trade http://www.orrtiz.com On Tue, Jul 14, 2015 at 12:04 PM, Radovan Semancik <[email protected]> wrote: On 07/14/2015 11:38 AM, Emmanuel Lécharny wrote: Good to know. 389ds is known to be a crappy LDAP server, this is one more proof... Agreed. But it is out there. And a good LDAP API should support even bad servers (with a proper options, of course). Secondly, 389ds seems to use a lot of non-numeric OIDs. What do you mean ? Things like mixed prefix and OIDs ? Things like this: attributetypes: ( nsAdminSIEDN-oid NAME 'nsAdminSIEDN' DESC 'Netscape defined attribute type' SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 X-ORIGIN 'Netscape' ) Which produces this error (with M31): Caused by: org.apache.directory.api.ldap.model.exception.LdapInvalidAttributeValueException: ERR_10006 Comparator OID nsAdminSIEDN-oid is not a valid OID at org.apache.directory.api.ldap.schema.loader.SchemaEntityFactory.getOid(SchemaEntityFactory.java:122) ~[api-all-1.0.0-M29-SNAPSHOT.jar:1.0.0-M29-SNAPSHOT] at org.apache.directory.api.ldap.schema.loader.SchemaEntityFactory.getAttributeType(SchemaEntityFactory.java:873) ~[api-all-1.0.0-M29-SNAPSHOT.jar:1.0.0-M29-SNAPSHOT] at org.apache.directory.api.ldap.schema.manager.impl.DefaultSchemaManager.addAttributeTypes(DefaultSchemaManager.java:784) ~[api-all-1.0.0-M29-SNAPSHOT.jar:1.0.0-M29-SNAPSHOT] at org.apache.directory.api.ldap.schema.manager.impl.DefaultSchemaManager.addSchemaObjects(DefaultSchemaManager.java:253) ~[api-all-1.0.0-M29-SNAPSHOT.jar:1.0.0-M29-SNAPSHOT] at org.apache.directory.api.ldap.schema.manager.impl.DefaultSchemaManager.load(DefaultSchemaManager.java:739) ~[api-all-1.0.0-M29-SNAPSHOT.jar:1.0.0-M29-SNAPSHOT] at org.apache.directory.api.ldap.schema.manager.impl.DefaultSchemaManager.loadDepsFirstRelaxed(DefaultSchemaManager.java:1260) ~[api-all-1.0.0-M29-SNAPSHOT.jar:1.0.0-M29-SNAPSHOT] at org.apache.directory.api.ldap.schema.manager.impl.DefaultSchemaManager.loadWithDepsRelaxed(DefaultSchemaManager.java:1202) ~[api-all-1.0.0-M29-SNAPSHOT.jar:1.0.0-M29-SNAPSHOT] at org.apache.directory.api.ldap.schema.manager.impl.DefaultSchemaManager.loadAllEnabledRelaxed(DefaultSchemaManager.java:988) ~[api-all-1.0.0-M29-SNAPSHOT.jar:1.0.0-M29-SNAPSHOT] I do not really undestand why the error message mentions comparator ... but the problem seems to be non-numeric OID in attributetype declaration. WIll do. Thanks for dealing with all those external LDAP server s! No problem. That's the least I can do. We need to support all major LDAP servers out there (IDM is sometimes quite a dirty business). So this means I have to test them anyway. -- Radovan Semancik Software Architect evolveum.com
