Menu
▾
▴
springframework-developer
|
From: <jue...@we...> - 2004-10-05 15:01:49
|
Rod, Rob, CGLIB guys, Have a look at the following: http://opensource.atlassian.com/projects/spring/browse/SPR-368 Is my analysis correct? I've nailed this down with the debugger, so I'm = pretty sure that it is. I'm not aware of any way to get around this, as it is fundamentally = caused by the way CGLIB works... Juergen |
|
From: Rod J. <ro...@in...> - 2004-10-05 20:17:57
|
Your analysis looked right to me. Unfortunate. There are certainly quite a few negative consequences of the CGLIB subclassing approach. It would be good if there were other options we could consider when proxying classes (the AopProxyFactory interface gives us a choice), but I'm not aware of anything that's equally convenient. Rod jürgen höller [werk3AT] wrote: > Rod, Rob, CGLIB guys, > > Have a look at the following: > > http://opensource.atlassian.com/projects/spring/browse/SPR-368 > > Is my analysis correct? I've nailed this down with the debugger, so I'm pretty sure that it is. > > I'm not aware of any way to get around this, as it is fundamentally caused by the way CGLIB works... > > Juergen > > > ------------------------------------------------------- > This SF.net email is sponsored by: IT Product Guide on ITManagersJournal > Use IT products in your business? Tell us what you think of them. Give us > Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more > http://productguide.itmanagersjournal.com/guidepromo.tmpl > _______________________________________________ > Springframework-developer mailing list > Spr...@li... > https://lists.sourceforge.net/lists/listinfo/springframework-developer > -- ____________________________________________________ Rod Johnson Interface21 - Spring Services from the Source http://www.springframework.com Founder, Spring Framework: http://www.springframework.org Author, "Expert One-on-One J2EE Development Without EJB" (May 2004, with Juergen Hoeller). http://www.amazon.com/exec/obidos/ASIN/0764558315/ Author, "Expert One-on-One J2EE Design and Development" (October 2002). http://www.amazon.com/exec/obidos/tg/detail/-/0764543857/ ____________________________________________________ Interface21 Limited Registered Office Summit House, 2-2a Highfield Road, Dartford, Kent DA1 2JY Registered in England and Wales No. 5187766 ____________________________________________________ |
|
From: Chris N. <ch...@si...> - 2004-10-06 00:53:18
|
Rod Johnson wrote: > Your analysis looked right to me. Unfortunate. There are certainly quite > a few negative consequences of the CGLIB subclassing approach. It would > be good if there were other options we could consider when proxying > classes (the AopProxyFactory interface gives us a choice), but I'm not > aware of anything that's equally convenient. I've posted a comment on how to work around this "feature" of CGLIB (it is a feature, really :-) If you want to proxy concrete classes your options are pretty limited, I think. One possibility you may not be aware of is that if you are proxying JavaBeans you could use net.sf.cglib.beans.BeanGenerator to generate a bean that has the same properties as your target bean. Then use the Enhancer to proxy the generated bean, dispatching to the target as appropriate. This way you avoid all issues with the superclass constructor being invoked, since the generated bean extends Object. Let me know if you want to explore this further. Chris |
|
From: Rob H. <ro...@ca...> - 2004-10-06 09:44:51
|
Chris,
I took a look at your suggested workaround and I started the basics of
an implementation. The problem I came up against is that when the
constructor is invoked by CGLIB, which in turn invokes a method, say
setName(), the call to invokeSuper() by the interceptor fails with:
net.sf.cglib.core.CodeGenerationException:
java.lang.ClassCastException-->null
at net.sf.cglib.core.ReflectUtils.newInstance(ReflectUtils.java:235)
at net.sf.cglib.core.ReflectUtils.newInstance(ReflectUtils.java:220)
at net.sf.cglib.core.ReflectUtils.newInstance(ReflectUtils.java:216)
at net.sf.cglib.proxy.Enhancer.createUsingReflection(Enhancer.java:566)
at net.sf.cglib.proxy.Enhancer.firstInstance(Enhancer.java:493)
at
net.sf.cglib.core.AbstractClassGenerator.create(AbstractClassGenerator.java:220)
at net.sf.cglib.proxy.Enhancer.createHelper(Enhancer.java:368)
at net.sf.cglib.proxy.Enhancer.create(Enhancer.java:280)
at
org.springframework.aop.framework.Cglib2AopProxy.getProxy(Cglib2AopProxy.java:178)
at
org.springframework.aop.framework.Cglib2AopProxy.getProxy(Cglib2AopProxy.java:142)
at
org.springframework.aop.framework.CglibProxyTests.testFoo(CglibProxyTests.java:144)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at junit.framework.TestCase.runTest(TestCase.java:154)
at junit.framework.TestCase.runBare(TestCase.java:127)
at junit.framework.TestResult$1.protect(TestResult.java:106)
at junit.framework.TestResult.runProtected(TestResult.java:124)
at junit.framework.TestResult.run(TestResult.java:109)
at junit.framework.TestCase.run(TestCase.java:118)
at junit.framework.TestSuite.runTest(TestSuite.java:208)
at junit.framework.TestSuite.run(TestSuite.java:203)
at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:421)
at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:305)
at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:186)
Caused by: java.lang.ClassCastException
at
org.springframework.aop.framework.CglibTestBean$$EnhancerByCGLIB$$5c148601$$FastClassByCGLIB$$7660a3f6.invoke(<generated>)
at net.sf.cglib.proxy.MethodProxy.invokeSuper(MethodProxy.java:167)
at
org.springframework.aop.framework.Cglib2AopProxy$MethodInvocationImpl.invokeJoinpoint(Cglib2AopProxy.java:914)
at
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:119)
at
org.springframework.aop.interceptor.NopInterceptor.invoke(NopInterceptor.java:39)
at
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:141)
at
org.springframework.aop.framework.Cglib2AopProxy$DynamicAdvisedInterceptor.intercept(Cglib2AopProxy.java:629)
at
org.springframework.aop.framework.CglibTestBean$$EnhancerByCGLIB$$5c148601.setName(<generated>)
at
org.springframework.aop.framework.CglibTestBean.<init>(CglibTestBean.java:14)
at
org.springframework.aop.framework.CglibTestBean$$EnhancerByCGLIB$$5c148601.<init>(<generated>)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(Unknown Source)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(Unknown
Source)
at java.lang.reflect.Constructor.newInstance(Unknown Source)
at net.sf.cglib.core.ReflectUtils.newInstance(ReflectUtils.java:228)
... 25 more
I'm a little lost at this point, any help you could give would be much
appreciated :)
Rob
Chris Nokleberg wrote:
>Rod Johnson wrote:
>
>
>>Your analysis looked right to me. Unfortunate. There are certainly quite
>>a few negative consequences of the CGLIB subclassing approach. It would
>>be good if there were other options we could consider when proxying
>>classes (the AopProxyFactory interface gives us a choice), but I'm not
>>aware of anything that's equally convenient.
>>
>>
>
>I've posted a comment on how to work around this "feature" of CGLIB (it is a
>feature, really :-)
>
>If you want to proxy concrete classes your options are pretty limited, I
>think. One possibility you may not be aware of is that if you are proxying
>JavaBeans you could use net.sf.cglib.beans.BeanGenerator to generate a bean
>that has the same properties as your target bean. Then use the Enhancer to
>proxy the generated bean, dispatching to the target as appropriate. This
>way you avoid all issues with the superclass constructor being invoked,
>since the generated bean extends Object. Let me know if you want to explore
>this further.
>
>Chris
>
>
>
>
>-------------------------------------------------------
>This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
>Use IT products in your business? Tell us what you think of them. Give us
>Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
>http://productguide.itmanagersjournal.com/guidepromo.tmpl
>_______________________________________________
>Springframework-developer mailing list
>Spr...@li...
>https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
>
>
|
|
From: Chris N. <ch...@si...> - 2004-10-06 17:11:24
|
Rob Harrop wrote: > I took a look at your suggested workaround and I started the basics of > an implementation. The problem I came up against is that when the > constructor is invoked by CGLIB, which in turn invokes a method, say > setName(), the call to invokeSuper() by the interceptor fails with: Make sure you are passing the proxy as the first argument to invokeSuper, not the target. Also, it may be better to move the logic earlier, i.e. into DynamicAdvisedInterceptor instead of MethodInvocationImpl. Chris |
|
From: Rob H. <ro...@ca...> - 2004-10-07 23:38:01
|
Doh! I made that change and it passes all tests now. I will tidy this up a bit and then commit. Cheers Chris. Rob Chris Nokleberg wrote: >Rob Harrop wrote: > > >>I took a look at your suggested workaround and I started the basics of >>an implementation. The problem I came up against is that when the >>constructor is invoked by CGLIB, which in turn invokes a method, say >>setName(), the call to invokeSuper() by the interceptor fails with: >> >> > >Make sure you are passing the proxy as the first argument to invokeSuper, >not the target. > >Also, it may be better to move the logic earlier, i.e. into >DynamicAdvisedInterceptor instead of MethodInvocationImpl. > >Chris > > > > >------------------------------------------------------- >This SF.net email is sponsored by: IT Product Guide on ITManagersJournal >Use IT products in your business? Tell us what you think of them. Give us >Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more >http://productguide.itmanagersjournal.com/guidepromo.tmpl >_______________________________________________ >Springframework-developer mailing list >Spr...@li... >https://lists.sourceforge.net/lists/listinfo/springframework-developer > > > > |
