directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel Lecharny <elecha...@gmail.com>
Subject Re: Remaining interceptor chain inner-calls
Date Wed, 16 Nov 2011 14:34:40 GMT
On 11/16/11 3:10 PM, Kiran Ayyagari wrote:
> On Wed, Nov 16, 2011 at 6:11 AM, Emmanuel Lecharny<elecharny@gmail.com>  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


Mime
View raw message