On Wed, Nov 2, 2011 at 4:04 PM, Emmanuel Lecharny <elecha...@gmail.com> wrote:
> Hi guys,
>
> I had a bit of time and I reviewed the interceptors today. And I had an idea
> which may be interesting to discuss.
>
> First, here is a table where all the interceptors operation are listed, and
> for each interceptor, I listed the operation they are processing :
>
> AciAuthorizationInterceptor : ACI
> AdministrativePointInterceptor : API
> AuthenticationInterceptor : AI
> ChangeLogInterceptor : CLI
> CollectiveAttributeInterceptor : CAI
> DefaultAuthorizationInterceptor : DAI
> EventInterceptor : EI
> ExceptionInterceptor : EXI
> JournalInterceptor : JI
> KeyDerivationInterceptor : KDI
> NormalizationInterceptor : NI
> OperationalAttributeInterceptor : OAI
> PasswordHashingInterceptor : PHI
> ReferralInterceptor : RI
> SchemaInterceptor : SI
> SubentryInterceptor : SEI
> TriggerInterceptor : TI
>
> ACI API AI CLI CAI DAI EI EXI JI KDI NI OAI PHI RI SI
> SEI TI
> add : x x x x x ? x x x x x x x x x
> x x
> bind : - - x - - - - - - - x - - - -
> - -
> compare : x - x - - - - - - - x - - - x
> - -
> delete : x x x x - x x x x - x - - x -
> x x
> getRootDSE : - - x - - - - - - - - - - - -
> - -
> hasEntry : x - x - - - - - - - x - - - -
> - -
> list : x - x - x x - x - - x x - - x
> x -
> lookup : x - x - x x - x - - x x - - x
> - -
> modify : x x x x x x x x x x x x x x x
> x x
> move : x x x x - x x x x - x x - x -
> x x
> moveAndRename : x x x x - x x x x - x x - x ?
> x x
> rename : x x x x - x x x x - x x - x x
> x x
> search : x - x - x x - - - - x x - - x
> x -
> unbind : - - x - - - - - - - - - - - -
> - -
>
> (It's interesting that there are two operations that should be processed by
> some interceptors, and that are not : it's most certainly a bug. They are
> marked with a '?' in this table)
>
> Now, we can see that all the operation are only processed by a few
> interceptors. I was thinking that it could be an option to list the
> mandatory interceptors for each operation, instead of letting the chain
> determinate if an interceptor will process this operation.
>
> In the Operation manager, we will then call all the needed interceptors
> chain for each operation. For instance, for a delete operation, we will
> proceed this way :
>
> operationManager.delete( DeleteOperationContext deleteContext )
> {
> // ThedeleteContext.getOperation() is used to get the correct list of
> interceptors for the operation,
> // as we may have more than one delete operation (see below)
> InterceptorChain deleteChain = directoryService.getInterceptors(
> deleteContext.getOperation() );
>
> deleteChain.delete( deleteContext );
> }
> The biggest advantage is that we know have a clear list of interceptors for
> each operation, and we cna expose this list to the user, who can add its own
> interceptor. We can even compute this chain by checking which operation an
> interceptor will handle, using reflection, when the interceptor is added in
> the chain.
>
> For internal operation, I'm quiet sure we should ask the nexus directly,
this really is required for implementing the transaction support in server
the chain reentry is really a big issue at the moment for determining
transaction boundaries
(and yes, ThreadLocal is not gonna help in this situation)
> instead of going through the chain again. However, we can perfectly proceed
> exactly the same way, by defining some other operation, like lookupInternal,
+1
> which describes the list of needed interceptors.
>
> One other advantage is that we will not go through N useless interceptor for
> each operation, speeding up (ok, marginaly but still) the operations.
>
> Lats, not least, I'm quite sure that if we expose the list of interceptors
> involved by each operation, we make it easier for someone who want to add an
> interceptor, as all those lists will be available through teh configuration,
> and not in the code, as it is atm. It also remove the need for interceptors
> bypasses, if we inject the type of operation we want to execute in the
> context (xxxContext.getOperation() will return the type of operation).
>
> It may sound a bit crazy, but I think it would work with a little impact on
> the existing code...
>
> thoughts ?
>
> -- Regards, Cordialement, Emmanuel Lécharny www.iktek.com
>
--
Kiran Ayyagari
