directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kiran Ayyagari <kayyag...@apache.org>
Subject Re: Some experiment result about the chain management
Date Tue, 08 Nov 2011 14:58:02 GMT
On Tue, Nov 8, 2011 at 4:08 AM, Emmanuel Lecharny <elecharny@gmail.com> wrote:
> 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 ?
>
nothing at the moment, will take a look at the code after committing.
>
> 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
>
>



-- 
Kiran Ayyagari

Mime
View raw message