Menu
▾
▴
RE: [Springframework-developer] Not leveraging the CGLIB cache
|
From: James C. <jim...@do...> - 2004-06-24 13:55:48
|
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
|
