directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel Lecharny <>
Subject [ServerEntry] Problem with bootsrap ...
Date Tue, 29 Jan 2008 10:59:37 GMT
Hi guys,

I'm facing another chicken-egg problem. I have changed the way 
Attributes are initialized, as I need to get the values to be 
normalized, in order to be able to do valid comparisons 
(attribute.contains( <something> ) must be able to tell if the 
<something> is present, depending on the Attribute normalizer. ie, if 
the attribute is a CN, where 'cn="a test', then attr.contains( "A    
TesT" ) should reply true, because cn normalizer transforms "A    TesT" 
to "a test".)

Now, here is the problem I met. While initializing the server, the 
schemas are loaded, then we call this method :

    public void loadEnabled( Registries targetRegistries ) throws 
         * We need to load all names and oids into the oid registry 
regardless of
         * the entity being in an enabled schema.  This is necessary 
because we
         * search for values in the schema partition that represent 
         * and other entities that are not loaded.  While searching 
these values
         * in disabled schemas normalizers will attempt to equate names 
with oids
         * and if there is an unrecognized value by a normalizer then 
the search
         * will fail.
         * For example there is a NameOrNumericOidNormalizer that will 
reduce a
         * numeric OID or a non-numeric OID to it's numeric form using 
the OID
         * registry.  While searching the schema partition for 
attributeTypes we
         * might find values of matchingRules in the m-ordering, 
m-equality, and
         * m-substr attributes of metaAttributeType definitions.  Now if 
an entry
         * references a matchingRule that has not been loaded then the
         * NameOrNumericOidNormalizer will bomb out when it tries to 
         * names of matchingRules in unloaded schemas to OID values 
using the
         * OID registry.  To prevent this we need to load all the OID's 
in advance
         * regardless of whether they are used or not.

The comment is interesting : it says that we load all names and OIDs. 
When it tries to load thIS ENTRY :

Attribute id : 'createTimestamp',  Values : ['20080129093912Z']
Attribute id : 'm-singleValue',  Values : ['TRUE']
Attribute id : 'm-obsolete',  Values : ['FALSE']
Attribute id : 'm-description',  Values : ['The domain name of the name 
server that was the primary source of data for this zone']
Attribute id : 'm-usage',  Values : ['USER_APPLICATIONS']
Attribute id : 'creatorsName',  Values : ['uid=admin,ou=system']
Attribute id : 'm-collective',  Values : ['FALSE']
Attribute id : 'm-oid',  Values : ['']
Attribute id : 'm-supAttributeType',  Values : ['apacheDnsDomainName']
Attribute id : 'm-noUserModification',  Values : ['FALSE']
Attribute id : 'objectClass',  Values : ['top', 'metaAttributeType']
Attribute id : 'm-syntax',  Values : ['']
Attribute id : 'm-name',  Values : ['apacheDnsSoaMName']
Attribute id : 'm-equality',  Values : ['caseIgnoreIA5Match']

I get a failure simply because the 'm-supAttributeType' attribute's 
value ('apacheDnsDomainName') is using a NameOrNumericIdNormalizer, 
which check that the apacheDnsDomainName's OID is already present, which 
is not the case.

What happens is that we load all the names in an order which is totally 
different from the expected hierarchical order. Here, 
'apacheDnsDomainName' should have been loaded *before* the 
'apacheDnsSoaMName' attribute.

I must admit that this failure is a direct consequence of the 
modification I have done in the ServerValue class (the idea was to 
ensure that the values are normalized as soon as they are loaded ), but 
I'm wondering if it's a good idea now.

This is also something which will become a problem soon : as we have to 
normalize values before being able to compare values or to check if a 
value contains something, we will have to create values in two steps :
1) load the value
2) normalize the value.

If we consider that we have a normalizerInterceptor which role is to 
normalize incoming requests ( and obviously, the attributes' values), it 
might be overkilling to automatically normalize values when creating them.

But on the other side, if we don't, then there are a lot of places in 
the server where we will have to specifically call the normalizer after 
having created a value.

So what should we do ?

I may create a special constructor or a special setter which request 
that a new value has to be normalized, just to be sure that it's 
something we don't forget to do.

wdyt ?

PS : Sorry if it seems confuse, but it's not the easiest part of the 
server ...

This is something I don't really get

cordialement, regards,
Emmanuel L├ęcharny

View raw message