Currently WebMvcConfigurer.configurePathMatch(...) is called as a side-effect of WebMvcConfigurationSupport.getPathMatchConfigurer(). This makes it quite hard to use in @Bean method since it's hard to tell if the @Bean method or the configurePathMatch(...) method will be called first.
You can see an example of this in Spring Data Rest where the restHandlerMapping bean would ideally have a PatternParser on the delegates before the afterPropertiesSet() method is called. The current solution of overriding configurePathMatch and calling setPatternParser directly is brittle because the parser is needed before afterPropertiesSet() is called. This leads to issues such as #26415
It's possible to work-around the issue by adding @DependsOn("mvcPathMatcher") which will indirectly trigger the WebMvcConfigurationSupport.getPathMatchConfigurer() method, but this isn't ideal.
I wonder if we could make PathMatchConfigurer or the PatternParser a @Bean so that it can be injected directly if it's needed?
Comment From: rstoyanchev
We could expose an mvcPatternParser bean that mirrors the mvcPathMatcher() bean and exposes a global PathPatternParser for use throughout the application. The restHandlerMapping bean in Spring Data REST would then make use of that and configure its own handler mappings before calling afterPropertiesSet.
The one catch is that by doing this Spring Data REST opts into always using parsed patterns, which may be a reasonable choice I think. It performs better and supports largely the same syntax (except for notably ** in any but the last segment of the path) so it should be transparent. What do you think @odrotbohm?
Comment From: rstoyanchev
I've added assertions in HandlerMapping implementations to ensure the PathPatternParser is rejected if it is too late and I've also added an mvcPatternParser bean. Spring Data REST can inject this bean into its mappings, effectively always opting into parsed patterns.
Comment From: rstoyanchev
@odrotbohm are the current changes sufficient in which case we can close this?
Comment From: odrotbohm
I think we're set. Fixes already in Spring Data REST master and supported branches for quite a while.
Comment From: rstoyanchev
Okay thanks.