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:[EMAIL PROTECTED]
> 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
> <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
>
>
>
> --
> Christian Essl http://jucas.sourceforge.net
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
