directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel L├ęcharny <>
Subject Re: Implementing Interceptor Extendibility, another way of doing things...
Date Thu, 03 Nov 2011 14:29:49 GMT
On 11/3/11 3:21 PM, Alex Karasulu wrote:
> On Thu, Nov 3, 2011 at 3:16 PM, Emmanuel Lecharny<>wrote:
>> On 11/3/11 12:54 PM, Alex Karasulu wrote:
>> - we have to store a aspect<->  interceptor map in the config too (DIT)
> -1
> Our proposed solution removes the need for this. The aspect an Interceptor
> implementation is associated with, is directly queried from the
> Interceptor. There is no need for this mapping at all. The mapping is in
> the code of the Interceptor. The Interceptor interface needs a getAspect()
> method that all interceptors must support.
hmmm... That means we have to go through all the existing interceptors 
in the init phase to create this mapping. Could work, yes. I didn't had 
that in mind, but this is definitively an option.

Now, if someone wants to add an interceptor to replace an existing one, 
we should allow it to get selected.

Let say someone want to use MyAuthnInterceptor instead of the 
AuthenticationInterceptor to handle the AUTHENT aspect. As the 
AuthenticationInterceptor is already present in the server, we have to 
find a way to not associate it with the AUTHENT aspect. One possible way 
would be to disable the AuthenticationInterceptor.

Does it make sense ?

>> - we must get rid of bypasses. They are far too numerous, and probably out
>> of control.
> 0
> I don't know the answer to this myself. We need more discussion for us to
> see if this is the case. I think each logical aspect managed in the
> configuration should expose not only a direct aspect list for each
> operation but also a set of aspects to bypass on re-entrant invocation.

We are going to check if we can get rid of them one by one. The idea is 
to directly call the nexus operation, and see if the server still works. 
It will take some time, hopefully Kiran is giving a hand here. More to 
come ...
>> Here is the list of all the bypasses we are using :
> Looking ... damn! OK we probably need another thread to clean up this mess
> but I don't think we can disregard bypass mechanisms all together. We need
> to clean this up, simplify it and get her done. I don't think we can just
> scrap bypasses otherwise you'll have incorrect operation and severe levels
> of inefficiency.

I really think we should use another logic here : instead of using 
bypasses, we should define internal operations for this purpose, with 
the same logic as above (ie associating a list of aspects, etc).

Emmanuel L├ęcharny

View raw message