Mailing-List: contact dev-help@directory.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Apache Directory Developers List" <dev@directory.apache.org>
Received-SPF: pass (nike.apache.org: domain of elecharny@gmail.com designates
 209.85.215.178 as permitted sender)
Message-ID: <4E982327.1000804@gmail.com>
Date: Fri, 14 Oct 2011 13:55:19 +0200
From: Emmanuel Lecharny <elecharny@gmail.com>
Reply-To: elecharny@apache.org
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6;
 rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1
MIME-Version: 1.0
To: Apache Directory Developers List <dev@directory.apache.org>
Subject: Re: [ApacheDS] Interceptor bypass mechanism on reentrant calls into
 the InterceptorChain
References: 
 <CADwPi+HUWgWoHVjTrMZ9CpGiRrHT3oKZmGtwoJ7EtMLzj1j7Xw@mail.gmail.com>
In-Reply-To: 
 <CADwPi+HUWgWoHVjTrMZ9CpGiRrHT3oKZmGtwoJ7EtMLzj1j7Xw@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

On 10/13/11 11:34 PM, Alex Karasulu wrote:
> I wanted to start a clean thread here regarding this bypass mechanism which
> should be independent of OSGi.
Good idea.

>
> 1). The InterceptorChain itself is a composite component whether we're
> talking OSGi or just COOP. Interceptors will be inserted into it and it
> should not be coupled to any Interceptor that is inserted into it's
> Interceptor list/array. Interceptors ideally should be decoupled and
> independent of one another.
Absolutely. Except that in some case, we are using some data structure 
declared in some other interceptors. Here is the list of current 
cross-dependencies :

authz -> event, subtree
event -> normalization
hash -> authn
schema -> authn, exception, normalization
subtree -> event, normalization
trigger -> subtree

We must move the utility classes that are the reason why we have those 
cross dependencies to core-shared. I'll do that as soon as I get the 
code building again.
>
> 2). Interceptors are used to apply aspects to the processing of various
> operations against the LDAP partitions. There are core aspects that must be
> applied. Some of these are authentication, authorization, error handling,
> and schema checking. The core Interceptors participating in these aspects
> sometimes need to be bypassed on reentrant calls because their effects
> should not be applied twice.
yes.
>
> 3). A modular dynamically reconfigurable server should be able to add and
> remove Interceptors on the fly or replacing existing core interceptors with
> alternatives.
Yes.
>
> 4). More than one Interceptor can be used to enable an aspect. There's no
> rule stating that you need one Interceptor per aspect. Furthermore an
> Interceptor can provide several aspects if an implementor decides to do so.
Yes.
>
> 5). The IC should expose a set of aspects for each intercepted operation
> which are excluded when the IC is re-entered for that operation. This is
> part of the IC configuration and should be exposed via class properties for
> simplicity.
(IC = InterceptorChain, FTR)

Yes, absolutely. It's done inside the interceptors atm, but we should 
find a better way to do that (a declarative way)
>
> 6). Each Interceptor exposes the set of aspects it participates in. This
> should be exposed via class properties for simplicity.
It reverts the logic : the Interceptor must say that it's not part of 
some processing, instead of letting the caller determinate if it should 
be called. However, it might be too restrictive in some cases. We may 
have an operations executed from two different places, but not requiring 
the same set of interceptors to be called. Applying the above logic 
defeat this approach.
>
> 7). Optionally an Interceptor may expose a class property which determines
> whether or not it should be excluded on reentrant operations. The IC uses
> this to exclude or include the Interceptor on all reentrant operations.
See above, same objection.
>
> This way when conducting a reentrant operation the IC bypasses all
> Interceptors participating in that operations set of excluded aspects. If
> the intersection between the set of aspects of the operation to be excluded
> with the set of aspects the Interceptor participates in is zero then that
> Interceptor is included. Otherwise the interceptor is excluded.

>
> Best Regards,
> -- Alex
>


-- 
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com