Le 15/08/2018 à 21:01, Stefan Seelmann a écrit :
> +1
> 
> * Verified checksums and signatures
> * Built source on Linux with OpenJDK 8 and 11-ea25
> * Run installer tests:
>     * bin, tar.gz and deb on Debian 9 With OpenJDK 8 and 11-ea24
>     * rpm on Fedora 21 (very old!) with Java 8
> 
> Note: when starting the server there is output like this:
> [18:19:00] ERROR [org.apache.directory.api.ldap.model.entry.Value] -
> ERR_13725_CANNOT_HANDLE_NAME_AND_OPTIONAL_UID_NORM I do not know how to
> handle NameAndOptionalUID normalization with obje...

Yes, this should be a warning.

What happens is that the server will load all the schemas, recursively,
and for each schema, the AT, OC, etc.... Some of them are loaded before
the parts they depend on. Each of the attributeTypes and Object classes
are checked against the registries, and if they don't exist, such an
error is produced. Then a workaround is applied:

...
            entry.addAttribute( attributeType, attributeValue ); //
Here, we will get an exception
        }
        catch ( Exception e )
        {
            // The attribute does not exist already, create a fake one
            if ( ( schemaManager != null ) && schemaManager.isRelaxed() )
// Here, we create a fake object waiting for the real one to be loaded

Later on, when all the schemas has finally been loaded, all those
temporary objects are discarded, and a global check is done, which means
if there is some missing AT, OC or anything else, and error will be
produced.

Typically, here, an attributeType's super attribute is not yet loaded in
the registry (apacheDnsDomainName):

version: 1
dn:
m-oid=1.3.6.1.4.1.18060.0.4.2.2.6,ou=attributeTypes,cn=apachedns,ou=schema
m-singlevalue: TRUE
m-obsolete: FALSE
m-description: The domain name of the name server that was the primary
source of data for this zone
m-usage: USER_APPLICATIONS
creatorsname: uid=admin,ou=system
m-collective: FALSE
m-oid: 1.3.6.1.4.1.18060.0.4.2.2.6
m-supattributetype: apacheDnsDomainName
m-nousermodification: FALSE
m-syntax: 1.3.6.1.4.1.1466.115.121.1.26
objectclass: metaAttributeType
objectclass: metaTop
objectclass: top
m-name: apacheDnsSoaMName
m-equality: caseIgnoreIA5Match

because attribute files are loaded in an order that is not the one we
can guaranty. That would be another story if the schema elements were
not in a distinct file for each one of them.

I agree there is room for improvement here, typically not storing each
AT, OC, etc in a separated file, but as a whole in a .schema file, as
it's done in OpenLDAP. OTOH, that would make the schema update way more
complex, as we would have to modify the schema file and create a new one
for each modification, while the way we work allows us to simply update
one single fle when we modify the schema.

It's a implementation choice.

Ideally speaking, we should mute the logs in this case, or make it a
warning, not a error.


-- 
Emmanuel Lecharny

Symas.com
directory.apache.org

Attachment: pEpkey.asc
Description: application/pgp-keys

Reply via email to