Re: [Springframework-developer] Re: CGLIB question

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

Chris,

Unfortunately I think there's a fatal flaw in my solution using CGLIB 1.0.
There are now two objects, even if the enhanced one starts off with the same
state. "Optimized" invocations go to the original target, advised ones to
the enhanced class and never to the original object. This is fine if there's
no conversational state but the results can, ahem, be rather interesting if
there is.

I can't see a way round this with CGLIB 1.0.

It seems that CGLIB 2.0 solves this problem, if the LazyLoaderCallback works
as I understand. If it does solve this problem, could you please send me the
sample code?

Also, since that would be a killer reason to go to CGLIB 2.0, I guess it
brings the whole version thing up again. CGLIB 2.0 isn't backward
compatible, is it, so it will break old versions of Hibernate?

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
>