Description
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:
- Incorrect @JmsListener parameter matching when the listener is a JDK proxy [SPR-13576] #18153 Incorrect
@JmsListener
parameter matching when the listener is a JDK proxy - @EventListener does not work if put it at method in class that implements interface [SPR-13650] #18226
@EventListener
does not work if put it at method in class that implements interface - Consistent bean type checking for endpoint handlers [SPR-13725] #18298 Consistent bean type checking for endpoint handlers
Referenced from: commits bc7bcab