Interceptor architecture rocks (was Component Lookup Strategies and Tradeoffs)

[Leo Simons <le...@apache.org>]

On Tue, 2002-10-01 at 17:38, Peter Donald wrote:
<snip/>

> Wait for Interceptors - they be magic.

<snip/>

> interface Releaseable
> {
>   void release();
> }
> 
> The magic thing about what I am going to propose in about amonth is that no 
> component will ever implement this interface ;)
> 
> Lets assume that every component is exposed via a proxy with an interceptor 
> chain attached to it. So when you invoke a method it will be passed through 
> each interceptor in chain. 
> 
> Just say our chain looks something like
> 
> Service Interface
>        |
>        v
> Pooling Interceptor
>        |
>        V
>  Target Method
> 
> Now lets just say that our pooling interceptor looks something like
> 
> Object invoke( Invocation i, InterceptorContext ctx )
> {
>   if( i.getMethod() == m_cachedReleaseMethod )
>   {
>     ObjectPool pool = (ObjectPool)ctx.get( ObjectPool.KEY );
>     Object object = ctx.remove( InterceptorContext.TARGET );
>     pool.release( object );
>     return null;
>   }
>   else
>   {
>     return ctx.invokeNext( i, ctx );
>   }
> }

<20 seconds of silence...>

WAAAAAAH! This is f****ing neat. It also means total re-architecture of
the container, but hey...that's all internals. IOW: I get it =)

I figured The Biggest Thing This Week would be Red Hat 8, but this is
such a big "gotcha", I think Pete's getting the honours.

We'll have to wait the rest of the month to see more? Shame....

cheers,

Leo


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: Interceptor architecture rocks (was Component Lookup Strategies and Tradeoffs)

[Peter Donald <pe...@apache.org>]

On Wed, 2 Oct 2002 09:33, Leo Simons wrote:
> On Tue, 2002-10-01 at 17:38, Peter Donald wrote:
> <snip/>
>
> > Wait for Interceptors - they be magic.
>
> <snip/>
>
> > interface Releaseable
> > {
> >   void release();
> > }
> >
> > The magic thing about what I am going to propose in about amonth is that
> > no component will ever implement this interface ;)
> >
> > Lets assume that every component is exposed via a proxy with an
> > interceptor chain attached to it. So when you invoke a method it will be
> > passed through each interceptor in chain.
> >
> > Just say our chain looks something like
> >
> > Service Interface
> >
> >        v
> > Pooling Interceptor
> >
> >        V
> >  Target Method
> >
> > Now lets just say that our pooling interceptor looks something like
> >
> > Object invoke( Invocation i, InterceptorContext ctx )
> > {
> >   if( i.getMethod() == m_cachedReleaseMethod )
> >   {
> >     ObjectPool pool = (ObjectPool)ctx.get( ObjectPool.KEY );
> >     Object object = ctx.remove( InterceptorContext.TARGET );
> >     pool.release( object );
> >     return null;
> >   }
> >   else
> >   {
> >     return ctx.invokeNext( i, ctx );
> >   }
> > }
>
> <20 seconds of silence...>
>
> WAAAAAAH! This is f****ing neat. It also means total re-architecture of
> the container, but hey...that's all internals. IOW: I get it =)
>
> I figured The Biggest Thing This Week would be Red Hat 8, but this is
> such a big "gotcha", I think Pete's getting the honours.

;)

Think of it this way. 

You use info to describe features of your object - whether these features be 
transaction, security, pooling, activation or whatever. Each Attribute 
effectively describes a different aspect of your object. This is effectively 
the client side view of the system.

These attributes are then mapped onto interceptor chains so that each object 
"type" may have a separate set of interceptor chains. You need a new feature 
(maybe you need a service to be a proxy for webservice) then you create a new 
interceptor, hook it into the chain decorate the info file a little and bam. 
Done.

Containers effectively become simple to write and differentiated on their 
infrastructure (ie their deployment format, their Pool/Activation 
characteristerics and so forth).

Now add in the concept of tools. Implement the J2EE deployment API for Avalon 
and we will be able to deploy into any server using ant tasks or any gui (ie 
Eclipse, Netbeans or whatever) that supports it. We support the J2EE 
Management interface and we get integration with existing infrastrucutre and 
management consoles. We add ant tasks for validation, verification, info 
generation and so forth and things get a lot nicer.

Info + Interceptor + Tools is where I see Avalon going and it will be great ;)

-- 
Cheers,

Peter Donald
'Most men would rather die than think. Many do.'
                             Bertrand Russell


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>