directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Gerald Turner (JIRA)" <>
Subject [jira] [Commented] (DIRAPI-154) Implement "online" OpenLDAP schema parsing in DefaultSchemaLoader
Date Thu, 22 Aug 2013 17:23:53 GMT


Gerald Turner commented on DIRAPI-154:

I progressed a little further by disabling the throw on errors and changing from loadAllEnabled()
to loadAllEnabledRelaxed():

  public void loadSchema( SchemaLoader loader ) throws LdapException
      SchemaManager tmp = new DefaultSchemaManager( loader );


      if ( !tmp.getErrors().isEmpty() )
        String msg = "there are errors while loading the schema";
        LOG.error( msg + " {}", tmp.getErrors() );
        // Ignore: throw new LdapException( msg );

Now the schema is loaded and the registries are full of schema objects, however a new kind
of error happens when retrieving attributes from searches:

  10:03:11,226 ERROR [] (main) ERR_04131
The value is expected to be a String attribute such as 'cn' is now stored as binary, toString:

  cn: '0x4A 0x42 0x6F 0x73 0x73 0x41 0x64 0x6D 0x69 0x6E '

BTW, I created a fresh/empty OpenLDAP installation (using Debian packaging), the messy duplicates
and other brokeness (reported in my previous comment, loadSchema.log attachment) is pretty
much the same - seems that OpenLDAP is distributed with dirty schemas.  Perhaps keep the 'isApacheDs'
and if false then use relaxed schema loading?

> Implement "online" OpenLDAP schema parsing in DefaultSchemaLoader
> -----------------------------------------------------------------
>                 Key: DIRAPI-154
>                 URL:
>             Project: Directory Client API
>          Issue Type: Improvement
>    Affects Versions: 1.0.0-M20
>            Reporter: Gerald Turner
>         Attachments: loadSchema.log, openldap-schema.ldif
> The constructor in DefaultSchemaLoader has the following comment:
>   // TODO Handle schema loading on other LDAP servers
> For OpenLDAP this would require searching subtree under cn=schema,cn=config and handling
attributes like:
>   olcAttributeTypes: {1}( NAME ( 'sn' 'surname' ) DESC 'RFC2256: last (family)
name(s) for which the entity is known by' SUP name )
>   olcObjectClasses: {4}( NAME 'person' DESC 'RFC2256: a person' SUP top STRUCTURAL
MUST ( sn $ cn ) MAY ( userPassword $ telephoneNumber $ seeAlso $ description ) )
> Note that there is also an 'olcObjectIdentifier' attribute type that seems to be used
to create macros for interpolation in OID's used in other attributes:
>   olcObjectIdentifier: OLcfg
>   olcObjectIdentifier: OLcfgAt OLcfg:3
>   olcObjectIdentifier: OLcfgOvAt OLcfgAt:3
>   olcObjectIdentifier: OMsyn
>   olcObjectIdentifier: OMsBoolean OMsyn:7
>   olcAttributeTypes: ( OLcfgOvAt:10.4 NAME 'olcUniqueStrict' DESC 'Enforce uniqueness
of null values' EQUALITY booleanMatch SYNTAX OMsBoolean SINGLE-VALUE )
> However this additional complexity seems to only be used for the internal/vendor-specific
schema itself (not 'core', 'nis', etc.).
> Attached is LDIF output of from searching cn=schema,cn=config.
> Mailing List reference:

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see:

View raw message