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

Consistent method selection for listeners and endpoint mappings [SPR-13654] #18230

Closed
spring-issuemaster opened this issue Nov 7, 2015 · 1 comment

Comments

Projects
None yet
2 participants
@spring-issuemaster
Copy link
Collaborator

commented Nov 7, 2015

Juergen Hoeller opened SPR-13654 and commented

Historically, we have several meant-to-be analogous method selection algorithms across the core framework: e.g. for request mappings, message mappings, JMS listeners, event listeners. Since those do not share a common algorithm implementation, they have different treatment of corner cases, in particular in case of a proxy vs target class scenario.

Most importantly, for common handler methods, we perform our expensive findAnnotation lookup twice since we're not reusing the initial result that triggered the inclusion in the candidate method set. Aside from consistency in the codebase, this part is primarily about startup performance for applications with many registered components of different types.

Along with #18153 and #18226, this should get addressed for 4.2.3 as well.


Affects: 4.2.2

Issue Links:

  • #18153 Incorrect @JmsListener parameter matching when the listener is a JDK proxy
  • #18226 @EventListener does not work if put it at method in class that implements interface
  • #18298 Consistent bean type checking for endpoint handlers

Referenced from: commits bc7bcab

@spring-issuemaster

This comment has been minimized.

Copy link
Collaborator Author

commented Nov 9, 2015

Juergen Hoeller commented

This is now refactored into org.springframework.core.MethodIntrospector, delegated to by all post-processors with analogous lookup purposes. Our two HandlerMethodSelector variants both delegate to that generalized class now and are marked deprecated themselves.

Juergen

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.