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

SourceForge Headquarters 1320 Columbia Street Suite 310 San Diego, CA 92101 +1 (858) 422-6466

Rob - here's the test case. Notice if you remove the line that makes
target.equals(target2) -> false, the test will pass fine.

Thanks for your help!
Tyson

public void testMultipleProxies() {
    ProxyFactory pf =3D new ProxyFactory(new Class[] { ITestBean.class =
});
            pf.setProxyTargetClass(true);

            MethodInterceptor static1 =3D new TransactionInterceptor();
            pf.addInterceptor(static1);

            TestBean target =3D new TestBean();
            TestBean target2 =3D new TestBean();

            pf.setTarget(target);
            pf.setExposeProxy(false);

            ProxyFactory pf2 =3D new ProxyFactory(new Class[] {
ITestBean.class });
            pf2.copyFrom(pf);

            pf2.addInterceptor(static1);
            pf2.setTarget(target2);

            //if you remove this line, the test will pass...
            target2.setAge(target.getAge()+1);

            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());

	}

-----Original Message-----
From: Rob Harrop [mailto:ro...@ca...]=20
Sent: Thursday, June 24, 2004 1:26 PM
To: spr...@li...
Subject: [Springframework-developer] Re: Not leveraging the CGLIB cache

Tyson,

If you can get me a test that fails I will fix the problem, just need to

know exactly what I am fixing.=20

Rob
Norris, Tyson writes:=20

> 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)=20
>=20
> 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.=20
>=20
>=20
> 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));=20
>=20
> affecting the equality of the advisors?=20
>=20
> I'll check into this theory some more...=20
>=20
> Thanks
> tyson=20
>=20
>=20
> -----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=20
>=20
> 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

> trees. The problem with the test that Tyson supplied was that the
first=20
>=20
> 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

> 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 =20
> 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.=20
>=20
> 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=20
>=20
> next few days.=20
>=20
> Rob=20
>=20
>=20
> On 22 Jun 2004, at 22:35, Norris, Tyson wrote:=20
>=20
>> Thanks for your efforts Rob!=20
>>
>> 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.=20
>>
>> 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=20
>>
>> 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".=20
>>
>> I'll keep digging on this as well.=20
>>
>> Thanks
>> tyson=20
>>
>> -----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),=20
>>
>> 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.=20
>>
>> 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.=20
>>
>> Rob
>> On 22 Jun 2004, at 09:21, Rob Harrop wrote:=20
>>
>>> Tyson,=20
>>>
>>> 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.=20
>>>
>>> Rob=20
>>>
>>> On 22 Jun 2004, at 01:34, Norris, Tyson wrote:=20
>>>
>>>> public void testMultipleProxies() {
>>>>     ProxyFactory pf =3D new ProxyFactory(new Class[] {
ITestBean.class
>>>> });
>>>>             pf.setProxyTargetClass(true);=20
>>>>
>>>>             MethodInterceptor static1 =3D new NopInterceptor();=20
>>>>
>>>> //            MethodInterceptor static2 =3D new
>>>> Advices.ReadDataInterceptor();=20
>>>>
>>>>             pf.addInterceptor(static1);
>>>> //            pf.addInterceptor(static2);=20
>>>>
>>>> //            Advisor static3 =3D new Advices.SetterPointCut(new
>>>> Advices.NopInterceptor());
>>>> //            Advisor static4 =3D new Advices.SetterPointCut(new
>>>> Advices.ReadDataInterceptor());
>>>> //
>>>> //            pf.addAdvisor(static3);
>>>> //            pf.addAdvisor(static4);=20
>>>>
>>>> //            pf.addAdvisor(new Advices.ObjectReturnPointCut(new
>>>> Advices.NopInterceptor()));=20
>>>>
>>>>             TestBean target =3D new TestBean();
>>>>             TestBean target2 =3D new TestBean();=20
>>>>
>>>>
>>>>             pf.setTarget(target);
>>>>             pf.setFrozen(true);
>>>>             pf.setExposeProxy(false);=20
>>>>
>>>>             ProxyFactory pf2 =3D new ProxyFactory(new Class[] {
>>>> ITestBean.class });
>>>>             pf2.copyFrom(pf);
>>>>             pf2.setTarget(target2);=20
>>>>
>>>>
>>>>             ITestBean proxy1 =3D (ITestBean) pf.getProxy();
>>>>             ITestBean proxy2 =3D (ITestBean) pf2.getProxy();=20
>>>>
>>>>             System.out.println(proxy1.getClass().getName());
>>>>             System.out.println(proxy2.getClass().getName());=20
>>>>
>>>>             assertTrue(proxy1.getClass() =3D=3D proxy2.getClass()); =

>>>>
>>>> 	}
>>>=20
>>>
>>>
>>> -------------------------------------------------------
>>> 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...=20
>>>
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>>>
>>=20
>>
>>
>> -------------------------------------------------------
>> 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=20
>>
>>=20
>>
>> -------------------------------------------------------
>> 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=20
>>
> =20
>=20
>=20
> -------------------------------------------------------
> 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

>=20
> =20
>=20
> -------------------------------------------------------
> 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
=20

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