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