Return-Path: 
 <commons-dev-return-47333-apmail-jakarta-commons-dev-archive=jakarta.apache.org@jakarta.apache.org>
Delivered-To: apmail-jakarta-commons-dev-archive@www.apache.org
Received: (qmail 59513 invoked from network); 5 Mar 2004 22:53:17 -0000
Received: from daedalus.apache.org (HELO mail.apache.org) (208.185.179.12)
  by minotaur-2.apache.org with SMTP; 5 Mar 2004 22:53:17 -0000
Received: (qmail 96558 invoked by uid 500); 5 Mar 2004 22:53:00 -0000
Delivered-To: apmail-jakarta-commons-dev-archive@jakarta.apache.org
Received: (qmail 96514 invoked by uid 500); 5 Mar 2004 22:53:00 -0000
Mailing-List: contact commons-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
List-Unsubscribe: <mailto:commons-dev-unsubscribe@jakarta.apache.org>
List-Subscribe: <mailto:commons-dev-subscribe@jakarta.apache.org>
List-Help: <mailto:commons-dev-help@jakarta.apache.org>
List-Post: <mailto:commons-dev@jakarta.apache.org>
List-Id: "Jakarta Commons Developers List" <commons-dev.jakarta.apache.org>
Reply-To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
Delivered-To: mailing list commons-dev@jakarta.apache.org
Received: (qmail 96498 invoked from network); 5 Mar 2004 22:53:00 -0000
Received: from unknown (HELO smtp004.mail.ukl.yahoo.com) (217.12.11.35)
  by daedalus.apache.org with SMTP; 5 Mar 2004 22:53:00 -0000
Received: from unknown (HELO CHRISTIAN) (christianessl@80.121.38.103 with
 login)
  by smtp004.mail.ukl.yahoo.com with SMTP; 5 Mar 2004 22:53:05 -0000
Date: Fri, 05 Mar 2004 23:55:33 +0100
To: Jakarta Commons Developers List <commons-dev@jakarta.apache.org>
Subject: Re: [HiveMind] Interceptors - CGLIB / Javassist comparison
References: <035b01c402f8$fa839990$6401a8c0@ALMIGHTYBEAST>
From: Christian Essl <christianessl@yahoo.de>
Content-Type: text/plain; format=flowed; charset=iso-8859-15
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Message-ID: <opr4evavfxwo6mmv@mail.yahoo.de>
In-Reply-To: <035b01c402f8$fa839990$6401a8c0@ALMIGHTYBEAST>
User-Agent: Opera7.23/Win32 M2 build 3227
X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N
X-Spam-Rating: minotaur-2.apache.org 1.6.2 0/1000/N

Oh yes I agree. I like the idea too. One set of interceptors per service 
makes things more clear.

The only thing which concerns me is that the 'which implementation for 
service' problem returns.

I am not sure wheter there is already resolved but still I was dreaming a 
bit on this problem and have to say I like this Spring hierarchy.

So I tought maybe a module could extend another module. Inheriting 
everything it does not overwrite. And than have injection based a third 
xml-file where <use module="a" for="b"> are defined.

But thats propably no new idea.

P.S.: Sorry I didn't check the documentation-source. The web-site is 
actually that up-to date that I get lazy.

On Fri, 5 Mar 2004 16:29:41 -0500, Howard M. Lewis Ship 
<hlshiplists@comcast.net> wrote:

>> Howard - if I remember right - last time on interceptor
>> ordering you said
>> something about bundles of interceptors. It did not realy
>> understand that.
>
> The issue is that if you contribute multiple interceptors to a service 
> extension point, you have to
> be concerned with order. This is an offshoot of the fact that any module 
> may contribute interceptors
> to any service extension point.  This extreme case complicates things 
> for the simple case.
>
> But what if you contribute a group of interceptors as a single 
> contribution? i.e.
>
> <implementation service-id="...">
>   <interceptor-group>
>     <interceptor service-id="A"/>
>     <interceptor service-id="B"/>
>   </>
> </>
>
> This clearly orders A before B and there's no guesswork, since the group 
> is contributed as a whole.
>
> Another option to explore is defining "sets" of interceptors to be 
> contributed (possibly as a group
> with known ordering).  So:
>
> <implementation service-id="...">
>    <interceptor-set set-id="Foo"/>
> </>
>
> <interceptor-set id="Foo">
>   <interceptor service-id="A"/>
>   <interceptor service-id="B"/>
> </>
>
> Perhaps the entire idea of contributing just an individual interceptor 
> is flawed; perhaps they
> should always be applied as a set or group, with the restriction that 
> only a single set/group may be
> applied.  Then we are no longer concerned with order.
>
> --
> Howard M. Lewis Ship
> Independent J2EE / Open-Source Java Consultant
> Creator, Tapestry: Java Web Components
> http://howardlewisship.com
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org



-- 
Christian Essl 

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org