Mailing-List: contact avalon-phoenix-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Avalon-Phoenix Developers List"
 <avalon-phoenix-dev@jakarta.apache.org>
Message-ID: <3D75F3DF.7050408@apache.org>
Date: Wed, 04 Sep 2002 13:51:59 +0200
From: Nicola Ken Barozzi <nicolaken@apache.org>
Reply-To: nicolaken@apache.org
Organization: Apache Software Foundation
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US;
 rv:1.1) Gecko/20020826
MIME-Version: 1.0
To: Avalon-Phoenix Developers List <avalon-phoenix-dev@jakarta.apache.org>
Subject: Re: [Interceptors] Definition and basic use cases
References: <3D74B243.3080205@apache.org>
 <200209042140.24973.peter@apache.org>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit


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>