Menu
▾
▴
[Springframework-developer] Re: Not leveraging the CGLIB cache
|
From: Rob H. <ro...@ca...> - 2004-06-24 20:26:18
|
Tyson,
If you can get me a test that fails I will fix the problem, just need to
know exactly what I am fixing.
Rob
Norris, Tyson writes:
> Thanks Rob - I need to test some more, but maybe this is a problem
> within the AbstractAutoProxyCreator class (which is what our app is
> using to generate proxied instances)
>
> I'll see if I modify my test case to accurately reflect the failures we
> get when using (a) the updated Cglib2AopProxy class and (b) the
> AbstractAutoProxyCreator instances.
>
>
> Maybe it has something to do with this snippet:
> for (Iterator it = allInterceptors.iterator();
> it.hasNext();) {
> Advisor advisor =
> this.advisorAdapterRegistry.wrap(it.next());
> proxyFactory.addAdvisor(advisor);
> }
>
> proxyFactory.setTargetSource(getTargetSource(bean, beanName));
>
> affecting the equality of the advisors?
>
> I'll check into this theory some more...
>
> Thanks
> tyson
>
>
> -----Original Message-----
> From: Rob Harrop [mailto:ro...@ca...]
> Sent: Thursday, June 24, 2004 6:28 AM
> To: spr...@li...
> Subject: Re: [Springframework-developer] Not leveraging the CGLIB cache
>
> 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
>>
>
>
>
> -------------------------------------------------------
> 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
|
