Mailing-List: contact commons-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
Message-ID: <4047755A.1020107@comcast.net>
Date: Thu, 04 Mar 2004 13:28:42 -0500
From: Harish Krishnaswamy <hkrishnaswamy@comcast.net>
User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207)
MIME-Version: 1.0
To: Jakarta Commons Developers List <commons-dev@jakarta.apache.org>
Subject: Re: [HiveMind] HiveMind ideas - interceptor categories
References: <024f01c40148$3beae760$6401a8c0@ALMIGHTYBEAST>
 <404636DC.4060209@comcast.net> <opr4bq19h3wo6mmv@mail.yahoo.de>
 <4046CEDC.40205@comcast.net> <opr4cmykiiwo6mmv@mail.yahoo.de>
In-Reply-To: <opr4cmykiiwo6mmv@mail.yahoo.de>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

The default ordering will certainly be good but any other level of 
abstractions for the ordering seems like unnecessary complications of 
what is supposed to be a simple thing. May be I am missing something here?

-Harish

Christian Essl wrote:

> Hi Harish,
>
> My ordering suggestion was not a genius one, it should just make the 
> current ordering a bit easier to use. I just thought if you had some 
> standard-ordering numbers this would be enough for 80 % of the cases. 
> The order-attribute would take for such standard numbers a string - 
> like a constant. If this was not enough you could always assign an 
> explicite number.
>
> Also for easier usage an interceptor-factory should (optional) give 
> its default order number. Ie the logging-interceptor is by default on 
> 500 a security interceptor on 10000.
>
> Thanks,
> Christian
>
> On Thu, 04 Mar 2004 01:38:20 -0500, Harish Krishnaswamy 
> <hkrishnaswamy@comcast.net> wrote:
>
>> Hi Christian,
>>
>> Welcome back!
>>
>> I know you have done some work on dynamic proxy interceptors before, 
>> I shall take a look at it and see if it helps.
>>
>> As far as interceptor ordering, I really don't see the benefit. Could 
>> you be more elaborate?
>>
>> -Harish
>>
>> PS. I am going to bed now, don't expect an immediate response ;)
>>
>> Christian Essl wrote:
>>
>>> Hallo,
>>> Congratulations that Hivemind is back. Sorry that I haven't mailed 
>>> before, but I was very busy and wasn't checking for HiveMind that 
>>> often anymore. Especially I want to apologize with Howard, whoes 
>>> mail I must have overseen.
>>>
>>>>>> - Why use Javassist instead of dynamic proxies?
>>>>>
>>>>>
>>>> I am yet to explore Javassist, but would certainly like to see some 
>>>> comments comparing it to Cglib2. I have seen some great reviews for 
>>>> it and not to mention its widespread use in other products.
>>>
>>>
>>>
>>> In most cases I'm not a big fan of JavaAssist interceptors too. 
>>> Furtunately HiveMind is very flexible. There is nothing which 
>>> prevents an InterceptorFactory to return a dynamic-proxy, 
>>> cglib-proxy etc. Maybe this could be better documented. However if 
>>> you use this aproach you have the full dyna-proxy overhead for each 
>>> interceptor. Therefore other aop-frameworks (Nanning, Dynaop, Spring 
>>> - all use cglib) use interceptor chains. And of course this 
>>> frameworks bring other stuff as well.
>>>
>>> So what I imagine is an interceptor-factory which uses one of this 
>>> aop-frameworks (my favorite would be dynaop) and is itself 
>>> configured by a config-point. This would than be quite easy to use 
>>> and would give HiveMind state-of-the-art AOP for nearly nothing. 
>>> Such an aproach would also make HiveMind more ready to use normal 
>>> Beans.
>>>
>>> Interceptor-ordering:
>>> Maybe a quick help would be to make the ordering-categories more 
>>> explicit in the xml-config. So that you could use something like 
>>> this: <interceptor service-id=".." order="security">. Maybe the 
>>> ServiceInterceptorFactories could even provide a default-value.
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
>
>

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