Turns out that this is an unintended side effect of our eligible advisor caching in 3.2, with the extracted AbstractAdvisingBeanPostProcessor base class accidentally applying its advisor before existing advisors for all subclasses - whereas previously only AsyncAnnotationBeanPostProcessor actually did that.
So for 3.2.2, I've added a "beforeExistingAdvisors" flag to AbstractAdvisingBeanPostProcessor. Just AsyncAnnotationBeanPostProcessor switches "beforeExistingAdvisors" to "true" by default. So effectively, MethodValidation/PersistenceExceptionTranslationPostProcessor apply after existing advisors by default again, fixing the 3.1->3.2 regression.
Note that those post-processors are not meant to participate in advisor ordering a la Ordered. If you want that degree of control, consider using the underlying MethodValidationInterceptor directly, associating it with an ordered Advisor of your choice along the rest of your AOP configuration.
Concerning mixing of annotation-driven PostProcessors/Interceptors and @Advices - wouldn't it be possible to deprecate the "old" stuff and rewrite it using @Advice (with ordering configurable through @EnableXy or xy:annotation-driven/), so we don't have to care about the source of the configuration (internal PostProcessor or user @Advice)?. In 4.0 perhaps? :)
Dejan Predovic opened SPR-10309 and commented
It seems it's impossible to create an
@Aspect
with a priority higher then an "old school" interceptor. It used to work with 3.1.x but broke in 3.2.0.Affects: 3.2 GA, 3.2.1, 3.2.2
The text was updated successfully, but these errors were encountered: