Return-Path: Delivered-To: apmail-jakarta-avalon-phoenix-dev-archive@apache.org Received: (qmail 76846 invoked from network); 4 Sep 2002 11:37:02 -0000 Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131) by daedalus.apache.org with SMTP; 4 Sep 2002 11:37:02 -0000 Received: (qmail 4797 invoked by uid 97); 4 Sep 2002 11:37:34 -0000 Delivered-To: qmlist-jakarta-archive-avalon-phoenix-dev@jakarta.apache.org Received: (qmail 4781 invoked by uid 97); 4 Sep 2002 11:37:33 -0000 Mailing-List: contact avalon-phoenix-dev-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Avalon-Phoenix Developers List" Reply-To: "Avalon-Phoenix Developers List" Delivered-To: mailing list avalon-phoenix-dev@jakarta.apache.org Received: (qmail 4769 invoked by uid 98); 4 Sep 2002 11:37:33 -0000 X-Antivirus: nagoya (v4218 created Aug 14 2002) Content-Type: text/plain; charset="iso-8859-1" From: Peter Donald To: "Avalon-Phoenix Developers List" Subject: Re: [Interceptors] Definition and basic use cases Date: Wed, 4 Sep 2002 21:40:24 +1000 User-Agent: KMail/1.4.2 References: <3D74B243.3080205@apache.org> In-Reply-To: <3D74B243.3080205@apache.org> X-Wisdom: A right is not what someone gives you; it's what no one can take from you. MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Message-Id: <200209042140.24973.peter@apache.org> X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N 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= =20 JBoss has it, as do most distributed component impls (ie CORBA, DCOM etc)= =2E Some of them define "clientside" interceptors and some define "server-sid= e"=20 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=20 "client". > 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 becaus= e > 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 ;) > 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=20 have the notiiiion of shared data storage area though and I guess that ma= y be=20 something we can consider after release. --=20 Cheers, Peter Donald Doubt is not a pleasant condition, but certainty is absurd. -- Voltaire=20 -- To unsubscribe, e-mail: For additional commands, e-mail: