On 10/14/11 3:15 PM, Alex Karasulu wrote:
On Fri, Oct 14, 2011 at 2:55 PM, Emmanuel Lecharny<[email protected]>wrote:
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
problems.
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
.getSimpleName() );
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
so.
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?
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.
Keep in mind that ByPasses are declared within interceptors, and are not
context-free.
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.
Okie. Anyway, right now, we are still using the same old logic...
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
