On 11/3/11 3:21 PM, Alex Karasulu wrote:
On Thu, Nov 3, 2011 at 3:16 PM, Emmanuel Lecharny<elecha...@gmail.com>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 :
http://pastebin.com/tYDMvGMZ
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).
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
