Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

AspectJ advisor always positioned behind an "old school" advisor [SPR-10309] #14943

Closed
spring-projects-issues opened this issue Feb 16, 2013 · 3 comments
Assignees
Labels
in: core type: bug
Milestone

Comments

@spring-projects-issues
Copy link
Collaborator

@spring-projects-issues spring-projects-issues commented Feb 16, 2013

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

@spring-projects-issues
Copy link
Collaborator Author

@spring-projects-issues spring-projects-issues commented Feb 19, 2013

@spring-projects-issues
Copy link
Collaborator Author

@spring-projects-issues spring-projects-issues commented Mar 13, 2013

Juergen Hoeller commented

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.

Hope that helps,

Juergen

@spring-projects-issues
Copy link
Collaborator Author

@spring-projects-issues spring-projects-issues commented Mar 13, 2013

Dejan Predovic commented

Great, thanks. :)

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? :)

@spring-projects-issues spring-projects-issues added type: bug in: core labels Jan 11, 2019
@spring-projects-issues spring-projects-issues added this to the 3.2.2 milestone Jan 11, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
in: core type: bug
Projects
None yet
Development

No branches or pull requests

2 participants