On Fri, Oct 14, 2011 at 5:22 PM, Emmanuel Lécharny <[email protected]>wrote:
> 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. > > 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
