avalon-phoenix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicola Ken Barozzi <nicola...@apache.org>
Subject Re: [Interceptors] Definition and basic use cases
Date Wed, 04 Sep 2002 11:51:59 GMT

Peter Donald wrote:
> On Tue, 3 Sep 2002 22:59, Nicola Ken Barozzi wrote:
> 
>>I'm looking into the concept of interceptors, and I'm starting to see
>>the value.
>>
>>What I regard as interceptors, is similar to what Tomcat calls valves,
> 
> 
> Actually I believe TC3 used to call them interceptors ;)
> 
> 
>>that is Components that intercept the call to a Service and can decide
>>to forward the call, filter it or reply directly; the same happens when
>>the forwarded call ends.
> 
> 
> Yep. It is a pattern fairly common to most "enterprise" architectures. ie 
> JBoss has it, as do most distributed component impls (ie CORBA, DCOM etc).
> 
> Some of them define "clientside" interceptors and some define "server-side" 
> interceptors while some architectures define both ;)
> 
> 
>>Now:
>>
>>  1) where are these defined? Application-wide in the assembly?
> 
> Possibly it could be per-application, per-component, per-service or even per 
> "client".

Ah. But physically, they should be declared in the assebbly.xml file I 
guess. Or also in environment?

>>  2) how can these be defined? Must they be attatched to a specific
>>Service compulsory or can they go also with any service invocation?
> 
> both ;)
> 
>>  3) Interceptors are Components as well; they need to be managed as
>>other Components, because they will most probably need a Context because
>>they are stateless. How do I define them in the assembly? Is there a
>>creation order problem? Dependencies?
> 
> Yep - Igor is already aware of this I believe ;)

Igor, any hints?

>>  4) Should the Context be the app-defined one? Shall the Context be
>>created per invocation and used only privately by the interceptors?
>>Shall it reside inside the app context via a defined key?
> 
> as in getBlockContext().getApplicationContext() ? Could do - Phoenix does not 
> have the notiiiion of shared data storage area though and I guess that may be 
> something we can consider after release.

It is needed because the interceptors need a place where to put data 
between invocations, since they are stateless.

I guess that

   contextualize(Context context){
    Context interceptorcontext = context.get("avalon:appcontext");
   }

could do.

-- 
Nicola Ken Barozzi                   nicolaken@apache.org
             - verba volant, scripta manent -
    (discussions get forgotten, just code remains)
---------------------------------------------------------------------


--
To unsubscribe, e-mail:   <mailto:avalon-phoenix-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:avalon-phoenix-dev-help@jakarta.apache.org>


Mime
View raw message