Return-Path: X-Original-To: apmail-directory-dev-archive@www.apache.org Delivered-To: apmail-directory-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id B9CA9789D for ; Fri, 11 Nov 2011 18:41:47 +0000 (UTC) Received: (qmail 86781 invoked by uid 500); 11 Nov 2011 18:41:47 -0000 Delivered-To: apmail-directory-dev-archive@directory.apache.org Received: (qmail 86615 invoked by uid 500); 11 Nov 2011 18:41:47 -0000 Mailing-List: contact dev-help@directory.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: "Apache Directory Developers List" Delivered-To: mailing list dev@directory.apache.org Received: (qmail 86605 invoked by uid 99); 11 Nov 2011 18:41:47 -0000 Received: from minotaur.apache.org (HELO minotaur.apache.org) (140.211.11.9) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 11 Nov 2011 18:41:47 +0000 Received: from localhost (HELO mail-wy0-f178.google.com) (127.0.0.1) (smtp-auth username elecharny, mechanism plain) by minotaur.apache.org (qpsmtpd/0.29) with ESMTP; Fri, 11 Nov 2011 18:41:47 +0000 Received: by wyh13 with SMTP id 13so4922602wyh.37 for ; Fri, 11 Nov 2011 10:41:45 -0800 (PST) MIME-Version: 1.0 Received: by 10.180.92.163 with SMTP id cn3mr15341366wib.26.1321036905531; Fri, 11 Nov 2011 10:41:45 -0800 (PST) Reply-To: elecharny@apache.org Received: by 10.180.100.225 with HTTP; Fri, 11 Nov 2011 10:41:45 -0800 (PST) In-Reply-To: References: <4EBCF114.90004@gmail.com> Date: Fri, 11 Nov 2011 19:41:45 +0100 Message-ID: Subject: Re: Last operation to remove from the Interceptorchain : Search, continued From: Emmanuel Lecharny To: Apache Directory Developers List Content-Type: multipart/alternative; boundary=f46d04388e657d47f604b179dfbb --f46d04388e657d47f604b179dfbb Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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 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 whe= n >> 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 > > --=20 Regards, Cordialement, Emmanuel L=E9charny www.iktek.com --f46d04388e657d47f604b179dfbb Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable It'es easierbecauseyou don't have tostepinto the Element classwhen = transiting fromone interceptorto another one:it's onbe stepless than us= ually.It's also easier because you don't have tostepthrough useless= interceptors when they don't implement the method.

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

One mor= e advantage : you *know* which interceptorsyou willgothrough, as it's s= tored 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 (o= rremove one),the new incoming operations will see the newly added(or remove= d) 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 clas= s name.This is the next step, but we already have the Map<String,Interce= ptor> in place for that.In fact, I think it's already ready :)

On Fri, Nov 11, 2011 at 2:57 PM, Alex Karasu= lu <akarasulu@= apache.org> wrote:
On Fri, Nov 11, 2011 at 11:55 = AM, Emmanuel Lecharny <elecharny@gmail.com> wrote:
Hi guys,

I was too sleepy yesterday, and my eyeballs were just rolling in every dire= ction, 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 Direct= oryService, and Bam! , it works.

We have now no more InterceptorChain, and debugging the server is a damn br= eath !

So there is call stack any lon= ger? Is this why it's easier? =A0

--
Best Regards,
-- Alex




--
Regards,
Cord= ialement,
Emmanuel L=E9charny
www.ik= tek.com
--f46d04388e657d47f604b179dfbb--