CAS 5.0 and 5.1 - Nested Proxies Causing Problems with @Scheduled
30 views
Skip to first unread message
Petr Strnad
May 23, 2017, 9:53:15 AM5/23/17
to CAS Community
Hello,
For some reason, there is a DefaultAdvisorAutoProxyCreator bean being created in CasApplicationContextConfiguration. However, Spring also automatically registers an AnnotationAwareAspectJAutoProxyCreator. Is there any reason for the DefaultAdvisorAutoProxyCreator bean to exist? Right now, it only causes issues:
It leads to the creation of nested proxies (com.sun.proxy.Proxy which contains a CGLIB proxy). This can cause ScheduledAnnotationBeanPostProcessor to fail to detect @Scheduled annotation, because the use of AopUtils.getTargetClass(bean) only resolves the first proxy (so instead of returning the class of the actual bean, it returns the class of the CGLIB proxy, which doesn't have the @Scheduled annotation).
This does not happen every time, because the order of BeanPostProcessors seems to be partially random - it only happens when both AnnotationAwareAspectJAutoProxyCreator and DefaultAdvisorAutoProxyCreator are registered before ScheduledAnnotationBeanPostProcessor. For example, on my local machine, the order of the BeanPostProcessors pretty much always 'aligns' and therefore @Scheduled works, but on our servers, about 80% of our packaged WARs fail.
However, if you put a breakpoint to where DefaultTicketRegistryCleaner bean is created and debug your way towards the post processors, you will always see that there are two ProxyCreators, even if the order of BeanPostProcessors is 'aligned' for @Scheduled to work (see the attachments)
For some reason, there is a DefaultAdvisorAutoProxyCreator bean being created in CasApplicationContextConfiguration. However, Spring also automatically registers an AnnotationAwareAspectJAutoProxyCreator. Is there any reason for the DefaultAdvisorAutoProxyCreator bean to exist? Right now, it only causes issues:
It leads to the creation of nested proxies (com.sun.proxy.Proxy which contains a CGLIB proxy). This can cause ScheduledAnnotationBeanPostProcessor to fail to detect @Scheduled annotation, because the use of AopUtils.getTargetClass(bean) only resolves the first proxy (so instead of returning the class of the actual bean, it returns the class of the CGLIB proxy, which doesn't have the @Scheduled annotation).
This does not happen every time, because the order of BeanPostProcessors seems to be partially random - it only happens when both AnnotationAwareAspectJAutoProxyCreator and DefaultAdvisorAutoProxyCreator are registered before ScheduledAnnotationBeanPostProcessor. For example, on my local machine, the order of the BeanPostProcessors pretty much always 'aligns' and therefore @Scheduled works, but on our servers, about 80% of our packaged WARs fail.
However, if you put a breakpoint to where DefaultTicketRegistryCleaner bean is created and debug your way towards the post processors, you will always see that there are two ProxyCreators, even if the order of BeanPostProcessors is 'aligned' for @Scheduled to work (see the attachments)
0 new messages