Yes, it would look a lot like the interceptor in commons proxy. I don't really know what the penalty would look like with the added layer of indirection. But, to me, it's all about ease of use. It's much easier to write an Interceptor (or use an existing one) than to write code using Javassist to generate a class that does the interception. Commons proxy (or some code borrowed from it) will take care of generating the classes for you that will call the appropriate methods downstream of your interceptor.
-----Original Message----- From: Achim Hügen [mailto:[EMAIL PROTECTED] Sent: Sunday, July 30, 2006 4:47 PM To: [email protected] Subject: Re: HM2 Interceptors... What does the ServiceInterceptor look like? Does it have a intercept method only like the interceptor in commons proxy? Won't there be a performance penalty when the interceptor call chain is built by an extra level of indirection? Achim Am Fri, 28 Jul 2006 14:54:01 +0200 schrieb James Carman <[EMAIL PROTECTED]>: > 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 > >
