commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Harish Krishnaswamy <>
Subject Re: [HiveMind] HiveMind ideas - interceptor categories
Date Thu, 04 Mar 2004 18:28:42 GMT
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?


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 
> <> 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:
>> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message