hivemind-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "James Carman" <ja...@carmanconsulting.com>
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 [mailto:hlship@gmail.com] 
Sent: Friday, July 28, 2006 9:55 AM
To: dev@hivemind.apache.org
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 <james@carmanconsulting.com> 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:james@carmanconsulting.com]
> Sent: Friday, July 28, 2006 8:54 AM
> To: dev@hivemind.apache.org
> 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



Mime
View raw message