`MethodIntrospector.selectMethods()` fails to detect bridge methods across ApplicationContexts

[RHarryH]

Spring Boot version: 3.2.3, 3.2.4 (Spring Core 6.1.4)
Java version: Temurin 17 (17.0.10)

Reproduced on Windows and Github Actions with Ubuntu 22.04.

Minimal example: https://github.com/RHarryH/spring-webmvc-github-issue

Description:

I have observed weird issue of WebMvcTest failure with code 405 instead of expected 200 because Spring does not resolve controller method based on the request url. 405 error happens when there are two endpoints with the same request url but different HTTP method. When request urls are different 404 error is thrown.

This happens only when specific hierarchy of controllers is used and when WebMvcTest is run after SpringBootTest (achieved by changing test class execution order in junit-platform.properties.

The hierarchy of the controllers is as follows:

• Controller interface defining endpoints and annotating them with @XMapping annotations
• AbstractController implementing delete method. Please not it is a package-private abstract class
• ActualController implementing remaining methods

The presence of AbstractController is the main cause of the issue. Working workaround is making it public.

When debugging tests SpringBootTest logs contains:

2024-04-07T12:01:20.781+02:00 DEBUG 33568 --- [           main] _.s.web.servlet.HandlerMapping.Mappings  : 
	c.a.i.ActualController:
	{POST [/v1/a]}: add(Body,BindingResult)
	{POST [/v1/a/{id}]}: update(UUID,Body,BindingResult)
	{DELETE [/v1/a/{id}]}: delete(UUID)

while WebMvcTest logs miss DELETE method:

2024-04-07T12:01:22.203+02:00 DEBUG 33568 --- [           main] _.s.web.servlet.HandlerMapping.Mappings  : 
	c.a.i.ActualController:
	{POST [/v1/a]}: add(Body,BindingResult)
	{POST [/v1/a/{id}]}: update(UUID,Body,BindingResult)

I have tracked down the rootcause to the org.springframework.core.MethodIntrocpector class and selectMethods(Class<?> targetType, final MetadataLookup<T> metadataLookup) method (

spring-framework/spring-core/src/main/java/org/springframework/core/MethodIntrospector.java

Line 75 in 9bd6aef

if (result != null) {

).

Line 74 correctly inspects the method. The problem is in line 77. When SpringBootTest tests are run the fields looks like below:

method = {Method@7492} "public void com.avispa.issue.AbstractController.delete(java.util.UUID)"
specificMethod = {Method@7493} "public void com.avispa.issue.ActualController.delete(java.util.UUID)"
result = {RequestMappingInfo@7494} "{DELETE [/v1/a/{id}]}"
bridgedMethod = {Method@7492} "public void com.avispa.issue.AbstractController.delete(java.util.UUID)"

But then whenWebMvcTest tests are run it looks like below:

method = {Method@9155} "public void com.avispa.issue.AbstractController.delete(java.util.UUID)"
specificMethod = {Method@9156} "public void com.avispa.issue.ActualController.delete(java.util.UUID)"
result = {RequestMappingInfo@9157} "{DELETE [/v1/a/{id}]}"
bridgedMethod = {Method@7492} "public void com.avispa.issue.AbstractController.delete(java.util.UUID)"

As you can see in second case method and bridgedMethod represents the same method but are in fact different instances of Method class. And because the comparison in line 77 is done by reference, it failes and does not add found DELETE method to the mappings registry.

When SpringBootTest tests are disabled, the problem does not exist.

[wilkinsona]

Thanks very much for the detailed report, analysis, and minimal example.

It turns out that this isn't a Spring Boot problem and that it can be reproduced with pure Spring Framework. For the problem to occur, two contexts must be involved. Using @WebMvcTest and @SpringBootTest achieves this, but the same can be achieved with any configuration where the tests' context configurations are different.

I've forked the example and pushed an update that removes Spring Boot. Its tests still fail in the same way and log similar output for the mappings:

11:15:06.563 [main] DEBUG _org.springframework.web.servlet.HandlerMapping.Mappings -- 
	c.a.i.ActualController:
	{POST [/v1/a]}: add(Body,BindingResult)
	{POST [/v1/a/{id}]}: update(UUID,Body,BindingResult)
	{DELETE [/v1/a/{id}]}: delete(UUID)

11:15:06.848 [main] DEBUG _org.springframework.web.servlet.HandlerMapping.Mappings -- 
	c.a.i.ActualController:
	{POST [/v1/a]}: add(Body,BindingResult)
	{POST [/v1/a/{id}]}: update(UUID,Body,BindingResult)

My suspicion at the moment is that the problem's due to some static-scoped caching during the method introspection. We'll transfer this issue to the Framework team so that they can continue the investigation.

[wilkinsona]

I should also have noted that I don't think this is even test-specific. I was also able to reproduce the problem (judging by the logging of the mappings) by adding a main method to the app in which I called SpringApplication.run(…).close() twice.