Provide caching for HandlerMappingIntrospector lookups

[rstoyanchev]

Spring Security relies on such lookups to align its request matching and CORS decisions with Spring MVC. However, it can perform the lookups multiple times per request, depending on the security configuration, and that can have a negative impact on performance, e.g. #31098.

We can expose a Filter to save and clear the result of a lookup in a request attribute before and after delegating to the rest of the filter chain. Spring Security can then integrate the Filter, allowing it to perform multiple calls without becoming a hotspot.

The solution needs to into account nested FORWARD and ERROR dispatches by checking for an existing value before replacing it, and also making sure it's restored at the end.

[rPraml]

Hello @rstoyanchev

this change breaks some of our UI-tests, which scans for warnings and errors in the log.
The test finds unexpected warnings like this

Cache miss for REQUEST dispatch to '/' (previous null). Performing CorsConfiguration lookup. 
This is logged once only at WARN level, and every time at TRACE.

As workaround I can turn off the logger for now. My question is: How critical is this cache miss? Can I fix it by adjusting my CORS configuration?

Thanks
Roland

[rstoyanchev]

@rPraml, Spring Security has not yet integrated this, see spring-projects/spring-security#14128, so at the moment this is expected. If you could check again with Spring Security snapshots once the issue is fixed, that would be great.

More generally, a cache miss does not mean that it won't work or will not make the right decision, but rather that the caching isn't used and there is an overhead in making repeated lookups to determine the target handler.