I'm not certain I'm convinced on tying the CorsFilter to a specific implementation of CorsConfigurationSource is a good idea. The problem is that the CorsFilter will only support CorsConfigurationMapping instead of any implementation of CorsConfigurationSource.
Another concern I have is that having logic like DEFAULT_PATH hardwired into the CorsFilter makes it difficult to support other PathMatcher implementations / instances which might be necessary to support path delimiters of "." instead of "/".
Instead you might consider CorsFilter having a setter method for CorsConfigurationSource. Users can then inject any implementation of CorsConfigurationMapping into the CorsFilter. All logic for determining the CorsConfiguration would be contained within the CorsConfigurationSource
User's could leverage the DelegatingFilterProxy to take advantage of the CorsFilter. If you really wanted to support using Filter init parameters, I think you could register a custom ConversionService that would convert from a String to the CorsConfigurationSource object you want.
If all the logic is contained in the CorsConfigurationSource implementation, it may be possible to reuse it within Spring MVC rather than having to repeat the logic (i.e. within the HandlerMappings).
You're right CorsFilter should allow to use any CorsConfigurationSource implementation.
I thought initially that providing a filter that works out of the box for users using only filter init params was mandatory, but after your feedback and more thoughts about this, I agree that using DelegatingFilterProxy + CorsConfigurationMapping make perfectly sense.
About sharing the logic between the filter and Spring MVC, that's why I introduced CorsConfigurationMapping, so I think this goal is already achieved.
I will update this commit shortly, and will notice you as soon as it is done.
Good catch, it was an unexpected side effect of the renaming of Map<String, CorsConfiguration> getConfiguration() to Map<String, CorsConfiguration> getConfigurations(), my IDE detected CorsConfiguration getConfiguration(Object handler, HttpServletRequest request) as an overloaded method, and renamed it as well (it asked me but I didn't notice). It is now fixed, thanks.