On Fri, Oct 14, 2011 at 2:55 PM, Emmanuel Lecharny <firstname.lastname@example.org>
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.
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 :
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.
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 problems.
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.
3). A modular dynamically reconfigurable server should be able to add and
remove Interceptors on the fly or replacing existing core interceptors with
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.
(IC = InterceptorChain, FTR)
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
Yes, absolutely. It's done inside the interceptors atm, but we should find a better way to do that (a declarative way)
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.
6). Each Interceptor exposes the set of aspects it participates in. This
should be exposed via class properties for simplicity.
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?
See above, same objection.
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.
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.