ando@sys-net.it wrote:
Full_Name: Pierangelo Masarati Version: HEAD (re23,...) OS: irrelevant URL: Submission from: (NULL) (87.28.220.33) Submitted by: ando
I think I've spotted a potential issue in back-config. When creating a custom object, say an overlay, the configuration objectClass should inherit from olcOverlayConfig. While adding the object via LDAP, however, if the ancestor class is not explicitly listed, the derived object must provide a co_ldadd() hook, otherwise addition fails.
Currently, the code uses all defined objectClasses and stops the first time a hook is available and it does not fail.
That was of course the designed and desired behavior...
It would be more sound, IMHO, to have something like:
- if the structural objectClass provides a co_ldadd() hook, use it; it is that
hook's responsibility to call the superior's one if required;
- if it doesn't, then climb the inheritance tree and call co_ldadd() for the
first occurrence of a valid one.
The point is that structural classes are not the only ones that matter here, and if you're creating an entry that has a special class, you must provide the necessary handlers for that class.
Climbing the inheritance tree seems an ok convenience for entries that don't explicitly list all their superior classes, but that should not have precluded the existing behavior (checking all of the explicitly listed classes, whether they are structural or auxiliary).