You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Christian Essl <ch...@yahoo.de> on 2004/03/04 19:00:10 UTC
Re: [HiveMind] HiveMind ideas - interceptor categories
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
<hk...@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
--
Christian Essl http://jucas.sourceforge.net
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [HiveMind] HiveMind ideas - interceptor categories
Posted by Harish Krishnaswamy <hk...@comcast.net>.
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
> <hk...@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
RE: [HiveMind] HiveMind ideas - interceptor categories
Posted by "Howard M. Lewis Ship" <hl...@comcast.net>.
I like the idea of a default order number for interceptors. The interceptor factory interface could
be extended to provide this value.
Another option would be to extend the places where your can use the ${...} syntax, so that you could
use a symbol as a logical name, i.e.
<interceptor service-id="foo.Bar" order="${order.bar}"/>
--
Howard M. Lewis Ship
Independent J2EE / Open-Source Java Consultant
Creator, Tapestry: Java Web Components
http://howardlewisship.com
> -----Original Message-----
> From: Christian Essl [mailto:christianessl@yahoo.de]
> Sent: Thursday, March 04, 2004 1:00 PM
> To: Jakarta Commons Developers List
> Subject: Re: [HiveMind] HiveMind ideas - interceptor categories
>
>
> 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
> <hk...@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
>
>
>
> --
> Christian Essl http://jucas.sourceforge.net
>
> ---------------------------------------------------------------------
> 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