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:[EMAIL PROTECTED]
http://www.osm.net
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
