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
