I could also see a more trivial case, where there is no decision making
going on. You just want to add an interceptor object to the service point,
period:
<implementation service-id="somemodule.SomeService">
<interceptor object="instance:com.myco.interceptor.LoggingInterceptor" />
</implementation>
Oh, and method choosing should be part of the framework. So, you could do:
<implementation service-id="somemodule.SomeService">
<interceptor object="instance:com.myco.interceptor.LoggingInterceptor"
method="do*" />
</implementation>
So, only methods starting with "do" would be intercepted. Maybe we could
add more selectors, too. Such as "class" and "annotation" which would only
intercept methods on objects of a specified class or methods that have a
specific annotation type (maybe @Transactional for instance). These
"selectors" could be somewhat similar to how you define "pointcuts" in
AspectJ.
Also, rather than having to hand the interceptor factories the service id,
etc., we should maybe come up with the concept of an "InvocationContext"
which would be set up by the "outer" proxies to identify the service id,
service interface, service point's Log object, etc. Then, the interceptors
could query that information at runtime to do with it what they may. The
InvocationContext could allow for user-defined attributes (String -> Object
map) kind of like in the servlet world and request attributes. The
InvocationContext is, of course, thread local. Sorry for throwing out so
many ideas at once, but I think these could really help make HM easier to
configure/use. Thoughts?
James
-----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
