directory-api mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Radovan Semancik <radovan.seman...@evolveum.com>
Subject Schema error handling
Date Tue, 18 Aug 2015 08:30:18 GMT
Hi,

I have found what I consider a bug during schema processing. The 
ObjectClassHelper buildMust and buildMay methods stopped when the first 
error was encountered. I think that this is not correct. They should 
continue until all the errors are detected. Stopping on first error will 
result in incomplete schema: the attributes until that error will be 
part of the schema, the attributes after the error will not. The result 
should be that either no attribute is part of the schema or all parsable 
atributes are part of the schema. So I took the liberty of fixing that 
in rev.1696365. I have chosen the latter approach as that seems to be 
more consistent with current implementation.

And also ... the side effect of that change is also the ability to 
process eDirectory schema. And this is also the way how I found this 
bug. As a fun fact, the eDirectory schema seems to contain two 
attributes with the same OID:

attributeTypes: ( 2.16.840.1.113719.1.39.42.1.0.38 NAME 
'sasNMASProductOptions ' SYNTAX 1.3.6.1.4.1.1466.115.121.1.40{64512} 
SINGLE-VALUE X-NDS_PUBLIC_READ '1' )
attributeTypes: ( 2.16.840.1.113719.1.39.42.1.0.38 NAME 
'rADIUSActiveConnectio ns' SYNTAX 1.3.6.1.4.1.1466.115.121.1.40{64512} 
X-NDS_NAME 'RADIUS:Active Con nections' X-NDS_NOT_SCHED_SYNC_IMMEDIATE '1' )

I could not believe my eyes when I've seen that. I still hope that this 
is really some kind of my error. But I have confirmed it in two 
independent instances of eDirectory 8.8.

-- 
Radovan Semancik
Software Architect
evolveum.com


Mime
View raw message