Howard - if I remember right - last time on interceptor ordering you said something about bundles of interceptors. It did not realy understand that.
I ask this because I think the proxy-based interceptors gain a lot of speed by using the same objects in a number of interceptors, which is lost if you mix them with class based interceptors. So ordering also becomes a performance issue.
On Fri, 5 Mar 2004 13:57:38 -0500, Howard M. Lewis Ship <[EMAIL PROTECTED]> wrote:
A valuable discussion. I think Javassist will have a slight edge based on lack of object
instantiation in the long run. I may be wrong. Doesn't really matter ... that why
ServiceInterceptorFactory is a service ... we may ultimately have all kinds of different
implementations based on whatever bytecode enhancement framework is handy ... or even JDK proxies.
-- Howard M. Lewis Ship Independent J2EE / Open-Source Java Consultant Creator, Tapestry: Java Web Components http://howardlewisship.com
-----Original Message----- From: Harish Krishnaswamy [mailto:[EMAIL PROTECTED] Sent: Friday, March 05, 2004 1:45 PM To: Jakarta Commons Developers List Subject: Re: [HiveMind] Interceptors - CGLIB / Javassist comparison
Seems that's what you said before ;) But nevermind this is a more-than-enough-pointer!
-Harish
Christian Essl wrote:
> Sorry I made a mistake I meant ProxyFactory.extend() not create(). > > On Fri, 05 Mar 2004 13:37:06 -0500, Harish Krishnaswamy > <[EMAIL PROTECTED]> wrote: > >> Absolutely! Thanks for the tips. So that's what I'll do. >> >> -Harish >> >> Christian Essl wrote: >> >>> Hi Harish, >>> >>> I agree with you that HiveMind should provide a simpler (second) >>> form to write interceptors. >>> >>> But before you waste your weekend looking at my code I have to tell >>> you that I did not use CGLIB but rather used Javassist to call >>> MethodInterceptors. And this was a mistake CGLIB is certainly better >>> for that. >>> >>> If you want to see how CGLIB is used take a look at one of the >>> aop-frameworks dynaop, spring or nanning. >>> >>> I persanlly like dynaop (while they use CGLIB 1) according to there >>> website dynaop is faster than the others (even than JBoss aop - >>> which uses Javassist). Dynaop is also well documented and not too >>> complex - while you can learn a lot. To start look at the >>> ProxyFactory.extend() method - as I see cglib is used only from in >>> there - and take a look at the ClassProxyInvocationHandler and its >>> super-class. >>> >>> I hope this helps a bit (certainly more than my code). >>> >>> Thanks, >>> Chris >>> >>> >>> >>> On Fri, 05 Mar 2004 13:06:05 -0500, Harish Krishnaswamy >>> <[EMAIL PROTECTED]> wrote: >>> >>>> Oops, sent to the wrong list! >>>> >>>> Harish Krishnaswamy wrote: >>>> >>>>> Hi, >>>>> >>>>> I decided to do some work on interceptors and wanted to find a >>>>> suitable solution and so tried out CGLIB and Javassist and here >>>>> are my initial findings. >>>>> >>>>> 1. Ease-of-use / clarity / maintainability - Obviously here, >>>>> anybody that has done a little bit of Javassist will agree that it >>>>> is in no way comparable to CGLIB when it comes to ease-of-use. >>>>> CGLIB is all plain Java and very straight forward and Javassist is >>>>> on the other end of the spectrum - pieces of string literals >>>>> patched together to form Java statements. >>>>> >>>>> 2. Performance - This is interesting. CGLIB has a disadvantage >>>>> here due to the number of parameters passed to the intercept >>>>> method. It turns out, all of the overhead is because of these >>>>> parameters that cannot be overcome (atleast AFAIK). With a single >>>>> counter interceptor I could make Javassist as much as ~4 times as >>>>> fast as CGLIB (~300% faster). And with more interceptors obviously >>>>> Javassist is more faster. Now, if I insert a method call in the >>>>> Javassist interceptor with 4 parameters, to my surprise the >>>>> performance is identical to the CGLIB interceptor. Would be really >>>>> nice if CGLIB can be designed around this problem. >>>>> >>>>> 3. Limitations - There are quite a few limitations with Javassist >>>>> that can be found on their website primary one for me being not >>>>> able to debug instrumented classes. I have not come across any >>>>> such limitations with CGLIB. >>>>> >>>>> From this intial study, it looks to me that we certainly need a >>>>> way to provide CGLIB interceptors to services. And that's what >>>>> I'll be doing this weekend. I know Christian has already done some >>>>> work on this, I'll see if I can reuse it. >>>>> >>>>> -Harish >>>>> >>>>> PS. I can post the code if anybody is interested. >>>>> >>>>> >>>> >>>> --------------------------------------------------------------------- >>>> 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] > > > >
--------------------------------------------------------------------- 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]
-- Christian Essl http://jucas.sourceforge.net
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
