Menu
▾
▴
Re: [Springframework-developer] Not leveraging the CGLIB cache
|
From: Rob H. <ro...@ca...> - 2004-06-24 14:14:30
|
James,
I didn't manage to get my hands on this much before the 1.0.2 release
so none of my changes are in that release. If you check out the HEAD
from CVS and run your test against that you should be able to get that
test to pass, plus you will see a bunch of other tests for this case.
There is still one optimisation left to be made - that is the cache
lookup is not so fast because I have yet to add a full implementation
for the CallbackFilter.hashCode() method but the caching now passes all
the tests defined CglibAopProxy including a few that had to be
commented out in the past.
Rob
On 24 Jun 2004, at 14:55, James Cook wrote:
> Rob,
>
> Thanks for your work in this area. I think you are saying that the
> 1.0.2
> release has the proper fixes in it so it should return the same class
> name
> for a CGLIB-proxied class?
>
> If so, we are not seeing that behavior in our simple unit test.
> Perhaps you
> can simulate its behavior during your investigation:
>
> public void testInstanceOf() throws Exception {
> MyDAO myDAO1 = (MyDAO) getSpringContext().getBean("test.myDAO");
> MyDAO myDAO2 = (MyDAO) getSpringContext().getBean("test.MyDAO");
> assertTrue("Beans looked up from Spring are not the same instance
> type.", myDAO1.getClass().isInstance(myDAO2));
> }
>
> We initialize a spring context with a dummy bean named "test.myDAO" and
> advise it with a simple DebugInterceptor we wrote.
>
> I still can't get this test to pass with the 1.02 release.
>
>> -----Original Message-----
>> From: spr...@li...
>> [mailto:spr...@li...] On
>> Behalf
>> Of Rob Harrop
>> Sent: Thursday, June 24, 2004 9: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
>
|
