directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel Lecharny <elecha...@gmail.com>
Subject Implementing Interceptor Extendibility, another way of doing things...
Date Wed, 02 Nov 2011 20:04:15 GMT
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, 
instead of going through the chain again. However, we can perfectly 
proceed exactly the same way, by defining some other operation, like 
lookupInternal, 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

Mime
View raw message