hivemind-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "James Carman" <>
Subject RE: HM2 Interceptors...
Date Sun, 30 Jul 2006 17:11:50 GMT
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 [] 
Sent: Friday, July 28, 2006 9:55 AM
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 <> 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 []
> Sent: Friday, July 28, 2006 8:54 AM
> To:
> Subject: HM2 Interceptors...
> All,
> The HiveMind interceptor facility has been a thorn in my side from the
> beginning (hence the MethodInterceptorFactory).  Writing interceptors is
> too complicated IMHO.  We should make it much simpler.  I would suggest
> we do away with the stack altogether, at least from a "client view."  We
> 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
> of wiring everything together to make sure that the method calls go
> 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
> every service point).  If the factory returns null, then the interceptor
> not applied.  Basically, a factory can now *decide* whether or not they
> 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
> is so that if annotations are used to make that decision and they're only
> 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.

View raw message