avalon-phoenix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen McConnell <mcconn...@apache.org>
Subject Re: [Interceptors] Definition and basic use cases
Date Wed, 04 Sep 2002 13:45:17 GMT


Nicola Ken Barozzi wrote:

>
> 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. 


+1

>
>

-- 

Stephen J. McConnell

OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net




--
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