Oooooh! Very nice! Just make sure you return Object, though. But, I like it! We'd just have to generate the class at runtime which calls that method. Cool idea!
-----Original Message----- From: Achim Hügen [mailto:[EMAIL PROTECTED] Sent: Monday, July 31, 2006 7:26 AM To: [email protected] Subject: Re: HM2 Interceptors... I agree, this would be really helpful. In an annotated module one could even write inline interceptors that doesn't need a separate class: public class MyModule() { @Interceptor(for="allServices" ...) public void loggingInterceptor(Invocation invocation) { log.debug("before....."); invocation.invoke() log.debug("after....."); } } Achim James Carman schrieb: > 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 >> >> >> > > > > >
