Menu
▾
▴
RE: [Springframework-developer] Not leveraging the CGLIB cache
|
From: Norris, T. <tys...@be...> - 2004-06-22 00:34:44
|
I using a single thread.=20
I modified the test below, to reproduce the problem. The main difference
is that I'm not using a "singleton" target; I create a new instance of
TestBean for the second proxy.=20
Note that I ran into this using the BeanNameAutoProxyCreator, and a
non-singleton targetsource. The AbstractAutoProxyCreator performs this
functionality in similar fashion (i.e. causing a new class generation
with each instantiation), unless I'm confused...
Hopefully I'm not missing the point, but I have assumed that since
"target", and "target2" are instances of the same class (but NOT the
same instance, as the test you mentioned first), and the interceptor is
a singleton, then I will get an instance of the same class back when a
proxy is generated from either target instance (i.e. CGLIB only
generates the class once).=20
Thanks for the feedback.
Tyson
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());
}
-----Original Message-----
From: Rob Harrop [mailto:ro...@ca...]=20
Sent: Monday, June 21, 2004 3:10 PM
To: spr...@li...
Subject: Re: [Springframework-developer] Not leveraging the CGLIB cache
Are you calling getBean() on different threads each time?
I have this test:
public void testMultipleProxies() {
=09
ProxyFactory pf =3D new ProxyFactory(new Class[] {
ITestBean.class });
pf.setProxyTargetClass(true);
MethodInterceptor static1 =3D new
Advices.NopInterceptor();
MethodInterceptor static2 =3D new
Advices.ReadDataInterceptor();
pf.addInterceptor(static1);
pf.addInterceptor(static2);
Advisor static3 =3D new Advices.SetterPointCut(new=20
Advices.NopInterceptor());
Advisor static4 =3D new Advices.SetterPointCut(new=20
Advices.ReadDataInterceptor());
pf.addAdvisor(static3);
pf.addAdvisor(static4);
=09
pf.addAdvisor(new Advices.ObjectReturnPointCut(new=20
Advices.NopInterceptor()));
TestBean target =3D new TestBean();
pf.setTarget(target);
pf.setFrozen(true);
pf.setExposeProxy(false);
ITestBean proxy1 =3D (ITestBean) pf.getProxy();
ITestBean proxy2 =3D (ITestBean) pf.getProxy();
=09
System.out.println(proxy1.getClass().getName());
System.out.println(proxy2.getClass().getName());
=09
assertTrue(proxy1.getClass() =3D=3D proxy2.getClass());
}
And it passes fine, however I have observed in the StaticAopTest class=20
in the load package that a different class is used for each thread in=20
the test suite runner. These classes have the same name with a _XX=20
suffix. This is not the same as before however when the class names=20
generated were completely different. I need to do a little more=20
investigation to see how Cglib implements the bytecode under all of=20
this.
Rob
On 21 Jun 2004, at 22:31, Norris, Tyson wrote:
> Rob et al -
> I've been trying out the changes in the Cglib2AopProxy class, and am
> still getting behavior where each instantiation of my proxied bean is
> iterating all the methods of the bean - as mentioned in jira issue
> SPR-175 (sorry for spreading this onto the mailing list - I thought
> others might have an opinion).
>
> I am concerned that my class is not properly getting cached by cglib.
>
> I have tried using the CVS version of Cglib2AopProxy (with the CVS
> version of cglib jar), and the classes returned by 2 consecutive calls
> to ApplicationContext.getBean(beanName) returns instances of the
> following classes:
>
> [my_class_name]$$EnhancerByCGLIB$$5ffa4f23_34@3452
>
> [my_class_name]$$EnhancerByCGLIB$$5ffa4f23_35@3455
>
> So I think the classes are not properly getting cached properly by
> CGLIB, although cglib's Key.hascode() is returning the same value in
> both cases (5ffa4f23).
>
> Anyhow, sorry if this is confusing, but I think there is a problem in
> there, but I haven't been able to get to the bottom of it.
>
> Thanks for any info or comments.
>
> Tyson
>
> -----Original Message-----
> From: Rob Harrop [mailto:ro...@ca...]
> Sent: Friday, June 11, 2004 2:46 PM
> To: spr...@li...
> Subject: Re: [Springframework-developer] Not leveraging the CGLIB
cache
>
> James (All),
>
> First I better introduce myself, my name is Rob Harrop and I have been
> working on the Cglib proxy class, fixing bugs and improving
> performance.
>
> The problem you mention is now fixed, but it does rely on the HEAD of
> Cglib (which I mistakenly checked into CVS without changing the name).
> The new CallbackFilter correctly implements hashCode so that Cglib can
> cache class instances.
>
> Rob
>
> On 11 Jun 2004, at 22:05, James Cook wrote:
>
>> Rod,
>>
>> Do you remember this issue? Has this one been addressed yet?
>>
>> http://article.gmane.org/gmane.comp.java.springframework.user/1502
>>
>> From: Chris Nokleberg <chris <at> sixlegs.com>
>> Subject: Re: CGLIB proxies are not assignable
>> Newsgroups: gmane.comp.java.springframework.user
>> Date: Sun, 11 Apr 2004 17:15:30 +0000
>>
>> Rod Johnson <rod.johnson <at> interface21.com> writes:
>>> This is the behaviour I would expect. As you say, maybe we should
>>> add it to the docs. All proxies _are_ instances of the class to be
>>> proxied.
>>
>> I actually think this is a bug. If the name of the class is changing
>> it means that caching of generated classes is not working correctly
>> --it is probably generating a new class per proxy. This will
obviously
>> slow down proxy creation tremendously and eventually cause
>> OutOfMemoryExceptions. The typical culprit is when you use a
>> custom CallbackFilter that does not implement equals/hashCode. I
>> don't have time right now but I'll take a look soon.
>>
>> Happy Easter
>> Chris
>>
>>
>>
>>
>>
>>
>> -------------------------------------------------------
>> This SF.Net email is sponsored by the new InstallShield X.
>> From Windows to Linux, servers to mobile, InstallShield X is the
>> one installation-authoring solution that does it all. Learn more and
>> evaluate today! http://www.installshield.com/Dev2Dev/0504
>> _______________________________________________
>> Springframework-developer mailing list
>> Spr...@li...
>>
https://lists.sourceforge.net/lists/listinfo/springframework-developer
>>
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by the new InstallShield X.
> From Windows to Linux, servers to mobile, InstallShield X is the
> one installation-authoring solution that does it all. Learn more and
> evaluate today! http://www.installshield.com/Dev2Dev/0504
> _______________________________________________
> 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
|
