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

[Rob H. <ro...@ca...>]

I think I have an at least partial answer on this, thanks to some  
englightenment from Chris N. As they I could not see the wood for the  
trees. The problem with the test that Tyson supplied was that the first  
proxy was advised and the second one was not! The  
ProxyFactory.copyFrom() method does not copy advisors. So as Chris  
pointed out we need to implement CallbackFilter.equals() to check that  
the CallbackFilters are for the same proxies. What confused me was - I  
knew we had this, Rod had added that some time ago. Then I noticed in  
the debugger that only the first proxy had the advisor, so Cglib was  
correctly returning a different proxy class. The rule of thumb is you  
will only get the same proxy class if the superclass and advice set is  
the same.

I took the opportunity to make a refactor suggested by Chris and I  
added a test to verify this case. I plan to improve the  
CallbackFilter.hashCode() implementation to increase performance in the  
next few days.

Rob


On 22 Jun 2004, at 22:35, Norris, Tyson wrote:

> Thanks for your efforts Rob!
>
> I suspected something along these lines as well, but also haven't been
> able to debug the cglib code enough to figure out why the class is not
> cached.
>
> This did bring to mind a post on cglib-devel list:
> http://sourceforge.net/mailarchive/forum.php? 
> thread_id=4141313&forum_id=
> 12922
>
> a problem with Factory.getCallback() method returning null when there
> were more than 38 methods. I don't see how this would impact the  
> caching
> of the class, but thought it might be worth a mention based on some
> complication arising from "too many methods".
>
> I'll keep digging on this as well.
>
> Thanks
> tyson
>
> -----Original Message-----
> From: Rob Harrop [mailto:ro...@ca...]
> Sent: Tuesday, June 22, 2004 1:33 PM
> To: spr...@li...
> Subject: Re: [Springframework-developer] Not leveraging the CGLIB cache
>
> Tyson (All),
>
> 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.
>
> I will raise this issue with the guys at Cglib, we are already
> discussing some other matters. But I think that we could also create
> our own cache as long we get all of the relevant parameters (not just
> superclass name) in the key for the cache. I will experiment with this
> and see where I get.
>
> Rob
> On 22 Jun 2004, at 09:21, Rob Harrop wrote:
>
>> Tyson,
>>
>> I have managed to narrow this down to occuring only on advised
>> targets. I anticipate this is a problem with the hashcode
>> implementation of one of the callbacks and I will hopefully have a fix
>
>> by the end of the day.
>>
>> Rob
>>
>> On 22 Jun 2004, at 01:34, Norris, Tyson wrote:
>>
>>> public void testMultipleProxies() {
>>>     ProxyFactory pf = new ProxyFactory(new Class[] { ITestBean.class
>>> });
>>>             pf.setProxyTargetClass(true);
>>>
>>>             MethodInterceptor static1 = new NopInterceptor();
>>>
>>> //            MethodInterceptor static2 = new
>>> Advices.ReadDataInterceptor();
>>>
>>>             pf.addInterceptor(static1);
>>> //            pf.addInterceptor(static2);
>>>
>>> //            Advisor static3 = new Advices.SetterPointCut(new
>>> Advices.NopInterceptor());
>>> //            Advisor static4 = new Advices.SetterPointCut(new
>>> Advices.ReadDataInterceptor());
>>> //
>>> //            pf.addAdvisor(static3);
>>> //            pf.addAdvisor(static4);
>>>
>>> //            pf.addAdvisor(new Advices.ObjectReturnPointCut(new
>>> Advices.NopInterceptor()));
>>>
>>>             TestBean target = new TestBean();
>>>             TestBean target2 = new TestBean();
>>>
>>>
>>>             pf.setTarget(target);
>>>             pf.setFrozen(true);
>>>             pf.setExposeProxy(false);
>>>
>>>             ProxyFactory pf2 = new ProxyFactory(new Class[] {
>>> ITestBean.class });
>>>             pf2.copyFrom(pf);
>>>             pf2.setTarget(target2);
>>>
>>>
>>>             ITestBean proxy1 = (ITestBean) pf.getProxy();
>>>             ITestBean proxy2 = (ITestBean) pf2.getProxy();
>>>
>>>             System.out.println(proxy1.getClass().getName());
>>>             System.out.println(proxy2.getClass().getName());
>>>
>>>             assertTrue(proxy1.getClass() == proxy2.getClass());
>>>
>>> 	}
>>
>>
>>
>> -------------------------------------------------------
>> This SF.Net email sponsored by Black Hat Briefings & Training.
>> Attend Black Hat Briefings & Training, Las Vegas July 24-29 - digital
>> self defense, top technical experts, no vendor pitches, unmatched
>> networking opportunities. Visit www.blackhat.com
>> _______________________________________________
>> Springframework-developer mailing list
>> Spr...@li...
>> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>>
>
>
>
> -------------------------------------------------------
> This SF.Net email sponsored by Black Hat Briefings & Training.
> Attend Black Hat Briefings & Training, Las Vegas July 24-29 -
> digital self defense, top technical experts, no vendor pitches,
> unmatched networking opportunities. Visit www.blackhat.com
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
>
> -------------------------------------------------------
> This SF.Net email sponsored by Black Hat Briefings & Training.
> Attend Black Hat Briefings & Training, Las Vegas July 24-29 -
> digital self defense, top technical experts, no vendor pitches,
> unmatched networking opportunities. Visit www.blackhat.com
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>