commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Howard M. Lewis Ship" <hlshipli...@comcast.net>
Subject RE: [HiveMind] HiveMind ideas - interceptor categories
Date Thu, 04 Mar 2004 18:15:17 GMT
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 
> <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
> 
> 
> 
> -- 
> 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


Mime
View raw message