On Wed, Nov 16, 2011 at 5:31 PM, Emmanuel Lecharny <firstname.lastname@example.org>
I think we can safely move the OperationalAttributeInterceptor after the SchemaInterceptor. This is important if we want to remove the re-entrant chain call for schema modifications, as we would then be able to continue the modification without having to go through all the interceptors.
When we try to modify the schema by modifying the subschemaSubentry entry (ie, cn=schema), we modify the attributes by adding (or removing) values, like :
injecting ( 22.214.171.124.4.1.655126.96.36.199.2.2 NAME 'templateObject' DESC 'test OC' SUP top STRUCTURAL MUST ( templateData $ cn ) X-SCHEMA 'other' ) into 'objectClasses'.
What happens then is that we go down the chain up to the SchemaInterceptor, where we parse the value, and then g through the full chain with the converted Entry. We can simply continue to process the entry starting from the SchemaInterceptor instead.
The only little trick is that we may have more than one modification, but that's not a big deal.
I'm going to try this approach.
OKIE - let us know how it works out.