On Wed, Nov 16, 2011 at 6:11 AM, Emmanuel Lecharny <[email protected]> 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 > www.iktek.com > >
-- Kiran Ayyagari
