[Springframework-developer] Re: CGLIB question

[Chris N. <ch...@si...>]

Rod Johnson wrote:

> Chris,
> 
> Actually I guess what I'm trying to do here doesn't make sense, and that
> CGLIB's behavior is correct.

I think your analysis is correct. :-)

> I need to override the method to invoke the original target via
> reflection. Otherwise I guess CGLIB creates a new subclass that won't
> invoke my instance, which is in the state I want after its properties have
> been set.

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.
 
> Does CGLIB provide any way of copying the state from my original instance
> of the class into the new subclass? Or would I need to write code to do
> that manually, assuming I could rely on the no-arg constructor and copy
> JavaBean properties?

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

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

>> Overall I really like CGLIB: it does what I expect of it with no fuss,
>> and it's a cool concept. But the Javadoc really is inadequate.

I know, it is improving for CGLIB2...another reason to upgrade ;-)

Chris