On Fri, Oct 14, 2011 at 5:22 PM, Emmanuel Lécharny <email@example.com>
On 10/14/11 3:15 PM, Alex Karasulu wrote:
1). The InterceptorChain itself is a composite component whether we're
Absolutely. Except that in some case, we are using some data structure
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.
declared in some other interceptors. Here is the list of current
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
Yep - pain for you I know but thanks for this. This should solve most of the
We have *UGLY* thinks done in interceptors : the AciAuthorizationInterceptor, for instance, is doing :
// perform checks below here for all non-admin users
SubentryInterceptor subentryInterceptor = ( SubentryInterceptor ) chain.get( SubentryInterceptor.class
Entry subentry = subentryInterceptor.getSubentryAttributes( dn, serverEntry );
Shit, my keyboard is now full of vomit :/
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
Ok, let's suppose we say that for an operation (lookup), an interceptor is configured to bypass it for internal operation. Good. But we may have some case where we may still want to go through this interceptor if the lookup is done from somewhere else (ie, in another interceptor), and in this case, we won't be able to go through it.
6). Each Interceptor exposes the set of aspects it participates in. This
It reverts the logic : the Interceptor must say that it's not part of some
should be exposed via class properties for simplicity.
processing, instead of letting the caller determinate if it should be
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
I'm sorry I did not fully understand this can you elaborate a little bit
further on this problem?
I see now thanks.
Keep in mind that ByPasses are declared within interceptors, and are not context-free.
You just triggered a new thought for me. What about keeping track of which interceptors have been triggered for each context? This might help us easily solve certain problems preventing reapplication. WDYT?
Okie. Anyway, right now, we are still using the same old logic...
This is how I see the bypass logic working with this inverted approach of
7). Optionally an Interceptor may expose a class property which determines
See above, same objection.
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
with the set of aspects the Interceptor participates in is zero then that
Interceptor is included. Otherwise the interceptor is excluded.
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.