Re: [Springframework-developer] Re: CGLIB question

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

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