On 11/16/11 3:10 PM, Kiran Ayyagari wrote:
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()
Because we have to add the Operational Attributes to the entries, and
this is done by the OpAttrInterceptors, before the SchemaInt :/
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
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
