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
