[Springframework-developer] Re: Not leveraging the CGLIB cache

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

Rob Harrop wrote:
> Some more news on this. Did some extensive testing on the train today
> and I am a bit stumped to be honest. The Cglib Key class that is
> created for both proxies is the same and therefore should use same
> class as the first instance, and indeed this works when the target is
> unadvised. I have two theories which I have been unable to test so far
> but hope to do so tomorrow/Thurs unless anyone else gets to it first.
> First theory (the unlikely one), is that the SoftReferences used to
> cache the proxy is being collected. Second, more likely theory, is that
> the Key class some how fails to work correctly when there are a certain
> number of callbacks. There are a LOT more callbacks created for advised
> targets than non advised targets.

Given that the Spring implementation of CallbackFilter (Cglib2AopProxy) uses 
a hard-coded hashCode value of zero, it is quite expected generated classes
that differ only in the set of advised methods will have names with the
same hash code portion, and be differentiated only by the numeric suffix.
If you think that two generated classes with different suffixes should
actually be the same class, that would point to an incorrect implementation
of Cglib2AopProxy.equals. CGLIB uses the equals method of the
CallbackFilter, among other things, to determine if a generated class is
the same as another (i.e. whether a new one needs to be generated).

It might be simpler to split off the CallbackFilter portion of
Cglib2AopProxy into it's own class, even an inner class. This way you could
separate the equals implementations for AopProxy and CallbackFilter (if it
turns out they need to be different). Also, for performance, the hash code
of the CallbackFilter should eventually be changed to reflect the set of
methods being advised. I think Rod looked into doing this once but ran into
some test suite failures.

Chris