commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christian Essl <christiane...@yahoo.de>
Subject Re: [HiveMind] Interceptors - CGLIB / Javassist comparison
Date Fri, 05 Mar 2004 19:53:44 GMT
Yes HiveMind is flexible! As far as I remember someone has already pointed 
out that this flexible aproach to interceptors is one HiveMind's main 
strengths.

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 
<hlshiplists@comcast.net> 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:hkrishnaswamy@comcast.net]
>> 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
>> > <hkrishnaswamy@comcast.net> 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
>> >>> <hkrishnaswamy@comcast.net> 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:
>> 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
>> >
>> >
>> >
>> >
>>
>> ---------------------------------------------------------------------
>> 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



-- 
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


Mime
View raw message