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
