Caching of ProducesRequestCondition in EndpointHandlerMapping may break custom HandlerMapping or ContentTypeResolver arrangements

[ykoyano]

Due to the optimization of ProducesRequestCondition, HandlerMapping caches MediaTypesAttribute.
However, WebFluxEndpointHandlerMapping and CloudFoundryWebFluxEndpointHandlerMapping do not delete the cached MediaTypesAttribute and affect the resolution of MediaTypes of other HandlerMappings. ( On the other hand, the class that inherits RequestMappingHandlerMapping deletes the cache.)

These issues are occurring not only in Spring Webflux's HandlerMapping but also in Spring MVC's HandlerMapping.

To solve this problem, I think you need one of the following measures:
Add a process to delete the cache at the end of HandlerMapping to AbstractWebFluxEndpointHandlerMapping and AbstractWebMvcEndpointHandlerMapping.
Move the process of deleting the cache at the end of HandlerMapping from RequestMappingHandlerMapping to RequestMappingInfoHandlerMapping of the parent class.

If my proposed solution is correct, I am ready to create a PR.

Related URL

• Side effect from ProducesRequestCondition cache with multiple RequestMappingHandlerMapping beans spring-framework#23091
• spring-projects/spring-framework@0757eae

[bclozel]

Hello @ykoyano

I can see how we might need to align here with Spring Framework - but the issue you've created only mentions the solution but not the actual problem. Did your application fail because of this problem? What was the problem, what were you trying to do and what was the expected behavior?

We need this type of information to properly triage this issue and assign the fix to a milestone.

[ykoyano]

Helllo @bclozel, thank you for the reaction.

In our team, we provided our own custom RequestedContentTypeResolver for RequestMappingHandlerMapping to convert our own accept header and content-type header. (This is because the accept header controls versioning.)

Usually, HandlerMapping is executed in the following order.

1. WebFluxEndpointHandlerMapping (HeaderContentTypeResolver)
2. ControllerEndpointHandlerMapping (HeaderContentTypeResolver)
3. RequestMappingHandlerMapping (CustomRequestedContentTypeResolver)

The value of MediaTypesAttribute cached by HeaderContentTypeResolver of WebFluxEndpointHandlerMapping is cleared when ControllerEndpointHandlerMapping ends.

However, for some reason, our team executed HandlerMapping in the following order. (I am aware that this is a rare case.)

1. WebFluxEndpointHandlerMapping (HeaderContentTypeResolver)
2. RequestMappingHandlerMapping (CustomRequestedContentTypeResolver)
3. ControllerEndpointHandlerMapping (HeaderContentTypeResolver)

In this case, the MediaTypesAttribute value cached by the HeaderContentTypeResolver of WebFluxEndpointHandlerMapping is inherited by RequestMappingHandlerMapping without being cleared. Therefore, we can no longer resolve the MediaTypesAttribute with the CustomRequestedContentTypeResolver.

Manipulating the HandlerMapping order can solve the above problem. However, if WebFluxEndpointHandlerMapping alone can clear the value of MediaTypesAttribute, can the value of MediaTypesAttribute be handled without depending on the order of HandlerMapping?
What do you think?

[bclozel]

Thanks @ykoyano for your contribution - your analysis is spot on and your use case helped triaging this issue!