Of course, I would suggest using Jakarta Commons Proxy to get this all working and become proxy implementation library agnostic (JDK proxies vs. CGLIB vs. Javassist). :-)
-----Original Message----- From: James Carman [mailto:[EMAIL PROTECTED] Sent: Friday, July 28, 2006 8:54 AM To: [email protected] Subject: HM2 Interceptors... All, The HiveMind interceptor facility has been a thorn in my side from the beginning (hence the MethodInterceptorFactory). Writing interceptors is way too complicated IMHO. We should make it much simpler. I would suggest that we do away with the stack altogether, at least from a "client view." We may very well use it internally, but requiring that a user push something onto the stack that implements the service interface is way too much to ask. Instead, service interceptor factories should return an Interceptor object instead and we (the HiveMind code actually) will take care of the hard work of wiring everything together to make sure that the method calls go through the interceptor on their way ultimately to the implementation object: public interface ServiceInterceptorFactory { public ServiceInterceptor createInterceptor( ServiceInterceptorFactoryParameters params ); } The parameters object would contain the usual stuff like the service id, service interface, module, etc. It would also contain a reference to the implementation object! Now, interceptor factories can be declared locally (for one service point) or globally (which means that they'll be applied to every service point). If the factory returns null, then the interceptor is not applied. Basically, a factory can now *decide* whether or not they want to contribute to the service point. This would allow us to "auto-proxy" service points. The reason that I added the impl object into the parameters is so that if annotations are used to make that decision and they're only on the impl class (like @Transactional). What do you guys think? James
