directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Karasulu <akaras...@apache.org>
Subject Re: [ApacheDS] Interceptor bypass mechanism on reentrant calls into the InterceptorChain
Date Sat, 15 Oct 2011 09:11:04 GMT
On Fri, Oct 14, 2011 at 5:22 PM, Emmanuel L├ęcharny <elecharny@apache.org>wrote:

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



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

-- 
Best Regards,
-- Alex

Mime
View raw message