Re: [Springframework-developer] Re: CGLIB question

[Rod J. <rod...@in...>]

The performance improvement is so big that perhaps we could autodect the
CGLIB version.

E.g. have two versions of the present CgligProxyFactory and load whichever
is appropriate, based on checking some class for CGLIB version. The only
problem is how do we make it compile? Class.forName would be nasty.

Regards,
Rod

----- Original Message ----- 
From: "Rod Johnson" <rod...@in...>
To: <spr...@li...>
Sent: Friday, November 28, 2003 4:42 PM
Subject: Re: [Springframework-developer] Re: CGLIB question


> Thanks Chris.
>
> Comments inline.
>
> > With CGLIB2 this would be pretty easy, since you can have multiple
> > interceptors per object. You could continue to use one MethodInterceptor
> as
> > usual for the advised methods, and for the others you could use
something
> > like the LazyLoader Callback, to redirect the method invocations to the
> > original object. This wouldn't use any reflection and wouldn't have to
> > build up an argument array, etc. I can send you sample code if you want.
> Sounds great. In the meantime I've written a little utility called
> ReflectionUtils.shallowCopyFieldState to copy fields from the target to
the
> new instance of the enhanced class created by CGLIB. Works nicely and it's
a
> useful little class anyway.
>
> > This is another option. The interceptor route still has a tiny bit of
> > overhead (an extra field dereference and method call), and you have to
> > carry around the old bean for the life of the proxy. If they really are
> > just JavaBeans you can use the net.sf.cglib.beans.BeanCopier class to
> > efficiently copy all of the properties from the old bean to the new bean
> > (it is really fast). In this case you would want to return false from
your
> > MethodFilter (in CGLIB1, in CGLIB2 you would use a NoOp Callback) to
allow
> > the original methods to be invoked (essentially it prevents the methods
> > from being generated in the new class, allowing the super version to be
> > used).
> I considered the bean copy route, but the object I was using in my
> application was actually Type 3 and we must now consider that as well.
Also,
> there may not be getter methods on the source: only setters.
>
> > >> It appears that now CGLIB is creating a new instance of the target
and
> > >> somehow now copying its state. Previously a property I'd set on the
> > >> target was visible through the proxy; now it isn't.
> > It extends the class but does not copy any fields--it doesn't know
> anything
> > about an actual "target" object instance, only the Class. I'm not sure
> what
> > the behavior you were seeing before was.
> I was puzzled for a while too. But it was behaving correctly because the
> reflective interception was hitting the old object in all cases.
>
> Thanks again. This optimization gives us a big performance increase on
> methods with no advice, as there's no Spring (or CGLIB) interception at
all
> now. So I'm adding methods to force the use of CGLIB for this
optimization,
> and we'll be using CGLIB in our benchmarks.
>
> Interestingly, CGLIB 1.0 performance vs DP performance seems pretty much
the
> same otherwise.
>
> Regards,
> Rod
>
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: SF.net Giveback Program.
> Does SourceForge.net help you be more productive?  Does it
> help you create better code?  SHARE THE LOVE, and help us help
> YOU!  Click Here: http://sourceforge.net/donate/
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>