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 11:55 AM, Emmanuel Lecharny <email@example.com> 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