Hi David, On 9/11/07, David Jencks <[EMAIL PROTECTED]> wrote: > I hope you guys don't run off and implement something for this > without first accepting or rejecting my proposal to eliminate > InterceptorConfiguration.
Don't worry, I'm just doing some retro-ingeneering atm. I won't implement anything different without a discussion on the ML. . > One possibility is to configure the interceptor chains in spring or > the equivalent. This is exactly what I was thinking about. But we may also consider other options. There are only about 5 or 6 different chains at the > moment IIUC so a "named chain" that is known to the container and > injected to the points that need it might work. So far, I found 10 chains in the server (a few of them like USER_LOOKUP are declared more than once, though, with different interceptors in their list) Then if someone adds > an interceptor in say the spring configuration they can decide > exactly which chains it belongs in. IIRC this is approximately what > jetspeed does with its interceptor chaings. That's something we may consider. > > OpenEjb takes a very different approach by not having the ability to > configure interceptor chains at all: if you want radically different > behavior you write a new container class. The problem with interceptors is that they may change the way the server behave, if you don't chain them in the right order, of if the added interceptor modify some values. For instance, an interceptor injecting an new attribute (virtual attributes, for instance) _must_ be added before the schemaService interceptor, which will check that this added attribute don't conflict with the entry's ObjectClasses. (it's just an exemple) There are some integration > points where most behavior anyone wants can be configured, such as > the geronimo integration. IIUC the basic point of view of this > approach is that there are only a very few points in the chain where > custonization is approprate, so only those points can be customized: > the correct behavior of the rest of the container is just hardcoded. I just reached the same conclusion. Insertion points might be defined. > Triggers/stored procedures form one such obvious extension point but > aren't currently powerful enough to be all that is needed. Possibly > a declarative referential integrity facility together with triggers > would be enough. Thanks for your mail, David. I think this is a very important discussion we are having, and hopefully Alex will bring some insight. I would also add that modifying the interceptor chain is not urgent at all. I would like to release 1.5.2 before that. Emmanuel -- Regards, Cordialement, Emmanuel Lécharny www.iktek.com
