On Thu, Nov 3, 2011 at 4:29 PM, Emmanuel Lécharny <email@example.com>
On 11/3/11 3:21 PM, Alex Karasulu wrote:
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.
On 11/3/11 12:54 PM, Alex Karasulu wrote:
- we have to store a aspect<-> interceptor map in the config too (DIT)
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.
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 ?
Yep exactly how I was thinking of handling this kind of scenario.
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 ...
- we must get rid of bypasses. They are far too numerous, and probably out
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.
Youch this is a lot of painful work and very error prone because you cannot know that you have the right data set to make sure you force out all the potential sticking points. But then again if we have full test coverage we can can know it's good up to a degree.
We should also have some reasoning exercise as to why or why not one aspect should be bypass for each operation.
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).
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
Ahhh ok I see. What not to bypass but what we must include. That's not bad we can do this as well it might be best. Don't know what the pros and cons of this are at this point.