directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Karasulu <>
Subject Re: [ApacheDS] Interceptor bypass mechanism on reentrant calls into the InterceptorChain
Date Fri, 14 Oct 2011 13:15:37 GMT
On Fri, Oct 14, 2011 at 2:55 PM, Emmanuel Lecharny <>wrote:

> 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.

Yep - pain for you I know but thanks for this. This should solve most of the

>> 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.

Let's think this reversion scenario through then with the way bypassing will
work. Perhaps it's better. I've just thought through the opposite
implementation mechanics in this email below.

> 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.

I'm sorry I did not fully understand this can you elaborate a little bit
further on this problem?

>> 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.
This is how I see the bypass logic working with this inverted approach of
mine. I have to run through the same exercise with the opposite scenario.
Will try to give some thought to that tonight while looking over the code.

Best Regards,
-- Alex

View raw message