directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel L├ęcharny <elecha...@apache.org>
Subject Re: [ApacheDS] Interceptor bypass mechanism on reentrant calls into the InterceptorChain
Date Fri, 14 Oct 2011 14:22:58 GMT
On 10/14/11 3:15 PM, Alex Karasulu wrote:
> On Fri, Oct 14, 2011 at 2:55 PM, Emmanuel Lecharny<elecharny@gmail.com>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


Mime
View raw message