directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel Lecharny <elecha...@gmail.com>
Subject Re: Some experiment result about the chain management
Date Tue, 08 Nov 2011 09:08:28 GMT
Hi,

this morning, after a short night of sleep, I was thinking that it could 
be better to compute the next interceptor into the OperationContext 
class, where we store the list of interceptors, instead of doing it into 
the AbstractInterceptor class.

thoughts ?


On 11/8/11 12:26 AM, Kiran Ayyagari wrote:
> On Mon, Nov 7, 2011 at 4:54 PM, Emmanuel Lecharny<elecharny@gmail.com>  wrote:
>> On 11/7/11 10:36 PM, Kiran Ayyagari wrote:
>>> On Mon, Nov 7, 2011 at 3:55 PM, Emmanuel Lecharny<elecharny@gmail.com>
>>>   wrote:
>>>> Hi guys,
>>>>
>>>> I played around some of the ideas we discussed last week on the mailing
>>>> list, about the way we handle the chain and the interceptors.
>>>>
>>>> What I did was pretty simple : I modified the way we process the
>>>> getRootDse() operation. This impact many classes :
>>>> o OperationContext :
>>>> This interface exposes 4 more methods :
>>>>   List<String>    getInterceptors() which returns the list of interceptors
>>>> to
>>>> execute for this operation
>>>>   void setInterceptors( List<String>    interceptors ) which sets the
list
>>>> of
>>>> interceptors to execute for this operation
>>> I would suggest we remove this mutable operation and fill the
>>> interceptor list with whatever there in the DS automatically
>> Absolutely. See what I suggest at the end.
>>
>>> And I think(purely random thinking) that exposing this interceptor
>>> list before lead to the convenient idea of 'let us use bypass list'
>>> to get past the re-entry issue
>> Not sure I get the idea you are trying to push here. Can you clarify ?
>>
> no, am just saying that leaving such constructs *might* lead to
> unintended usage
>>> o AbstractOperationContext :
>>> This is where we implement the four added methods.
>>>
>>> ...
>>>     /** The interceptors to call for this operation */
>>>     protected List<String>    interceptors;
>>>
>>> I would prefer not to expose this to the subclasses
>> +1
>>
>>>>     /** The current interceptor position */
>>>>     protected int currentInterceptor;
>>>> ...
>>>>     public AbstractOperationContext( CoreSession session )
>>>>     {
>>>>         this.session = session;
>>>>         currentInterceptor = 0;
>>>>     }
>>>> ...
>>>>     public List<String>    getInterceptors()
>>>>     {
>>>>         return interceptors;
>>>>     }
>>>>
>>>>     public void setInterceptors( List<String>    interceptors )
>>>>     {
>>>>         this.interceptors = interceptors;
>>>>     }
>>>>
>>> and removing the above setter
>> We can take care of this. Its just a proof of concept atm.
> okie
>>>> o Interceptor :
>>>> The second main difference. We don't pass anymore the NextInterceptor
>>> I think we can still achieve the behavior of next.add() with
>>> next(opContext)
>>> and continue executing (definitely possible now, but just saying)
>> This is what is done. Did I missed something ?
>>
> yeah, I know, but just wanted to reiterate that
>>
>> --
>> Regards,
>> Cordialement,
>> Emmanuel L├ęcharny
>> www.iktek.com
>>
>>
>
>


-- 
Regards,
Cordialement,
Emmanuel L├ęcharny
www.iktek.com


Mime
View raw message