directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kiran Ayyagari <>
Subject Re: Remaining interceptor chain inner-calls
Date Wed, 16 Nov 2011 14:10:58 GMT
On Wed, Nov 16, 2011 at 6:11 AM, Emmanuel Lecharny <> wrote:
> Hi guys,
> the last operations that re-enter the chain are associated with the schema
> modifications. More specifically, it's when someone modify cn=schema that we
> have to re-enter the chain.
> Here is an example where someone wants to add a new AT. He has two ways to
> do that :
> - either inject a LDIF entry, containing a description of the newly added
> AT. In this case, we will first update the schema on disk (ou=schema) then
> update the registry (cn=schema)
> - or he can modify the cn=schema AttributeTypes AT by adding a new value
> (using the RFC format). In this case, we parse the description, we update
> the registries,and then we translate the description to a plain Entry, and
> we now re-enter the chain with this entry to be added or deleted.
> Note that in the last case, we may have more than one modification done in
> one single request (as it's a ModifyRequest), thus we may re-enter the chain
> many times.
> At first, I thought we could avoid re-entering the chain, as none of the
> interceptors before the SchemaInterceptor are useful when we re-enter the
> chain. Except that the OperationalAttributeInterceptor is mandatory, to add
> the CreationDate and ModifiersName AT.
AFAIU the only reason we re-enter the chain is to add these
attributes, in that case why not extract that
method to a util class and apply the changes on the entry and push
directly to nexus.XXX()
> That leaves us with no option but to re-enter the chain.
> Now, the problem is how to deal with this constraints, knowing that most of
> the interceptors are useless, and that the BYPASS we used is now no more
> usable...
> I have no real solution atm this is way I posted this mail. Any suggestion
> is welcomed !
> --
> Regards,
> Cordialement,
> Emmanuel L├ęcharny

Kiran Ayyagari

View raw message