On Fri, Oct 14, 2011 at 2:55 PM, Emmanuel Lecharny <[email protected]>wrote:
> On 10/13/11 11:34 PM, Alex Karasulu wrote: > >> I wanted to start a clean thread here regarding this bypass mechanism >> which >> should be independent of OSGi. >> > Good idea. > > > >> 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. > > >> 2). Interceptors are used to apply aspects to the processing of various >> operations against the LDAP partitions. There are core aspects that must >> be >> applied. Some of these are authentication, authorization, error handling, >> and schema checking. The core Interceptors participating in these aspects >> sometimes need to be bypassed on reentrant calls because their effects >> should not be applied twice. >> > yes. > > >> 3). A modular dynamically reconfigurable server should be able to add and >> remove Interceptors on the fly or replacing existing core interceptors >> with >> alternatives. >> > Yes. > >> >> 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. >> > Yes. > > >> 5). The IC should expose a set of aspects for each intercepted operation >> which are excluded when the IC is re-entered for that operation. This is >> part of the IC configuration and should be exposed via class properties >> for >> simplicity. >> > (IC = InterceptorChain, FTR) > > Yes, absolutely. It's done inside the interceptors atm, but we should find > a better way to do that (a declarative way) Cool. > > >> 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? > > >> 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. -- Best Regards, -- Alex
