在由另一个增强器或 CglibAopProxy 生成的代理上创建一个增强器
create an enhancer on a proxy generated by another Enhancer or an CglibAopProxy
我们必须通过Cglib构建一些Proxy，有时代理的"superclass"可以是Cglib或CglibAopProxy生成的另一个代理。
但是在我们将 spring 从 3.0.6 更改为 4.2.4 后，事情变得很奇怪。
proxy和aop一起使用的话，两者都不行，直接调用用户class的方法。（用spring 3.0.6看起来不错，不知道为什么）
我追查了堆栈，发现CglibAopProxy生成的proxy会有这样的字段：
CGLIB$BOUND=false CGLIB$CALLBACK_0=DynamicAdvisedInterceptor@8186
CGLIB$CALLBACK_1=StaticUnadvisedInterceptor@8535
...
我们用这个proxy的class作为Enhancer的superclass后，看起来像：
CGLIB$BOUND=true
CGLIB$CALLBACK_0=InvokeHandler@8399 (the MethodInterceptor we added)
CGLIB$CALLBACK_1=null
...
CGLIB$CALLBACK_6=null
ExampleController$$EnhancerBySpringCGLIB$ab2772f.CGLIB$BOUND=true
ExampleController$$EnhancerBySpringCGLIB$ab2772f.CGLIB$CALLBACK_0=null
InvokerHandler 内部有一个由 CglibAopProxy 生成的代理实例。我们将在 InvokerHandler
中调用它
我们希望调用首先进入InvokeHandler，然后处理aop，然后调用用户class。但是因为这个问题，我们永远无法继续。
嗯...
我发现cglib和spring的cglib无法相互检测。所以，Enhancer.isEnhanced() 失败了。所以，super class 成为了 CGLIB 的 Proxy Class。
所以，外部代理 class 坏了。
所以，我们检测class名字中的“$$”，如果有，就去superclass，直到没有“$$”。然后，它起作用了（也许）。
我们必须通过Cglib构建一些Proxy，有时代理的"superclass"可以是Cglib或CglibAopProxy生成的另一个代理。
但是在我们将 spring 从 3.0.6 更改为 4.2.4 后，事情变得很奇怪。 proxy和aop一起使用的话，两者都不行，直接调用用户class的方法。（用spring 3.0.6看起来不错，不知道为什么）
我追查了堆栈，发现CglibAopProxy生成的proxy会有这样的字段：
CGLIB$BOUND=false CGLIB$CALLBACK_0=DynamicAdvisedInterceptor@8186 CGLIB$CALLBACK_1=StaticUnadvisedInterceptor@8535
...
我们用这个proxy的class作为Enhancer的superclass后，看起来像：
CGLIB$BOUND=true CGLIB$CALLBACK_0=InvokeHandler@8399 (the MethodInterceptor we added) CGLIB$CALLBACK_1=null ... CGLIB$CALLBACK_6=null ExampleController$$EnhancerBySpringCGLIB$ab2772f.CGLIB$BOUND=true ExampleController$$EnhancerBySpringCGLIB$ab2772f.CGLIB$CALLBACK_0=null
InvokerHandler 内部有一个由 CglibAopProxy 生成的代理实例。我们将在 InvokerHandler
中调用它我们希望调用首先进入InvokeHandler，然后处理aop，然后调用用户class。但是因为这个问题，我们永远无法继续。
嗯...
我发现cglib和spring的cglib无法相互检测。所以，Enhancer.isEnhanced() 失败了。所以，super class 成为了 CGLIB 的 Proxy Class。 所以，外部代理 class 坏了。
所以，我们检测class名字中的“$$”，如果有，就去superclass，直到没有“$$”。然后，它起作用了（也许）。