Menu
▾
▴
RE: [Springframework-developer] Not leveraging the CGLIB cache
|
From: Norris, T. <tys...@be...> - 2004-06-24 18:04:53
|
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 =3D allInterceptors.iterator();
it.hasNext();) {
Advisor advisor =3D
this.advisorAdapterRegistry.wrap(it.next());
proxyFactory.addAdvisor(advisor);
}
=09
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...]=20
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 =20
englightenment from Chris N. As they I could not see the wood for the =20
trees. The problem with the test that Tyson supplied was that the first
proxy was advised and the second one was not! The =20
ProxyFactory.copyFrom() method does not copy advisors. So as Chris =20
pointed out we need to implement CallbackFilter.equals() to check that =20
the CallbackFilters are for the same proxies. What confused me was - I =20
knew we had this, Rod had added that some time ago. Then I noticed in =20
the debugger that only the first proxy had the advisor, so Cglib was =20
correctly returning a different proxy class. The rule of thumb is you =20
will only get the same proxy class if the superclass and advice set is =20
the same.
I took the opportunity to make a refactor suggested by Chris and I =20
added a test to verify this case. I plan to improve the =20
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?=20
> thread_id=3D4141313&forum_id=3D
> 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 =20
> 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 =3D new ProxyFactory(new Class[] { =
ITestBean.class
>>> });
>>> pf.setProxyTargetClass(true);
>>>
>>> MethodInterceptor static1 =3D new NopInterceptor();
>>>
>>> // MethodInterceptor static2 =3D new
>>> Advices.ReadDataInterceptor();
>>>
>>> pf.addInterceptor(static1);
>>> // pf.addInterceptor(static2);
>>>
>>> // Advisor static3 =3D new Advices.SetterPointCut(new
>>> Advices.NopInterceptor());
>>> // Advisor static4 =3D new Advices.SetterPointCut(new
>>> Advices.ReadDataInterceptor());
>>> //
>>> // pf.addAdvisor(static3);
>>> // pf.addAdvisor(static4);
>>>
>>> // pf.addAdvisor(new Advices.ObjectReturnPointCut(new
>>> Advices.NopInterceptor()));
>>>
>>> TestBean target =3D new TestBean();
>>> TestBean target2 =3D new TestBean();
>>>
>>>
>>> pf.setTarget(target);
>>> pf.setFrozen(true);
>>> pf.setExposeProxy(false);
>>>
>>> ProxyFactory pf2 =3D new ProxyFactory(new Class[] {
>>> ITestBean.class });
>>> pf2.copyFrom(pf);
>>> pf2.setTarget(target2);
>>>
>>>
>>> ITestBean proxy1 =3D (ITestBean) pf.getProxy();
>>> ITestBean proxy2 =3D (ITestBean) pf2.getProxy();
>>>
>>> System.out.println(proxy1.getClass().getName());
>>> System.out.println(proxy2.getClass().getName());
>>>
>>> assertTrue(proxy1.getClass() =3D=3D 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 -=20
digital self defense, top technical experts, no vendor pitches,=20
unmatched networking opportunities. Visit www.blackhat.com
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer
|
