directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kiran Ayyagari <kayyag...@apache.org>
Subject Re: Implementing Interceptor Extendibility, another way of doing things...
Date Thu, 03 Nov 2011 13:19:34 GMT
On Wed, Nov 2, 2011 at 4:04 PM, Emmanuel Lecharny <elecharny@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

Mime
View raw message