Are you concerned because with the implementation object, they could potentially circumvent any downstream interceptors by just invoking it directly instead of allowing the invocation to "proceed"?
-----Original Message----- From: Howard Lewis Ship [mailto:[EMAIL PROTECTED] Sent: Friday, July 28, 2006 9:55 AM To: [email protected] Subject: Re: HM2 Interceptors... I think this is a good approach. I'm a little nervous about exposing the implementation instance ... perhaps it should be just the implementation class? And remember that the implementation class itself may have been fabricated at runtime. On 7/28/06, James Carman <[EMAIL PROTECTED]> wrote: > 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 > > > > -- Howard M. Lewis Ship TWD Consulting, Inc. Independent J2EE / Open-Source Java Consultant Creator and PMC Chair, Apache Tapestry Creator, Apache HiveMind Professional Tapestry training, mentoring, support and project work. http://howardlewisship.com
