directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel Lecharny <>
Subject Re: Last operation to remove from the Interceptorchain : Search, continued
Date Fri, 11 Nov 2011 18:41:45 GMT
It'es easierbecauseyou don't have tostepinto the Element classwhen
transiting fromone interceptorto another one:it's onbe stepless than
usually.It's also easier because you don't have tostepthrough
uselessinterceptors when they don't implement the method.

Just test it, you'llseeimmediately how better it is.

One more advantage : you *know* which interceptorsyou willgothrough, as
it's stored into the OpContextas a list.

Th ebeauty is that we haven't lost any feature we had : you can still add a
new interceptoron the fly (orremove one),the new incoming operations will
see the newly added(or removed) interceptor. Of course, it's protected by
read/write locks, so there is no chance (well,I hope) that the list gets FU
by twoconcurrent threads.

The next stepwill be to identify Interceptors by a name,not by the class
name.This is the next step, but we already have the Map<String,Interceptor>
in place for that.In fact, I think it's already ready :)

On Fri, Nov 11, 2011 at 2:57 PM, Alex Karasulu <> wrote:

> On Fri, Nov 11, 2011 at 11:55 AM, Emmanuel Lecharny <>wrote:
>> Hi guys,
>> I was too sleepy yesterday, and my eyeballs were just rolling in every
>> direction, making my brain driving me in bad direction.
>> The issue I had was that the interceptors initialization was removed when
>> I removed the InterceptorChain initialisation. I added it back in the
>> DirectoryService, and Bam! , it works.
>> We have now no more InterceptorChain, and debugging the server is a damn
>> breath !
> So there is call stack any longer? Is this why it's easier?
> --
> Best Regards,
> -- Alex

Emmanuel L├ęcharny

View raw message