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 <http://www.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 > >
