On Thu, Nov 3, 2011 at 4:29 PM, Emmanuel Lécharny <elecha...@apache.org>wrote:
> 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 ? > > > Yep exactly how I was thinking of handling this kind of scenario. > >> >> - 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 ... > > 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. > >> >> 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). > > > 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. -- Best Regards, -- Alex
