Isn't the change in DispatcherServletPathProvider a breaking change between 2.0.3 and 2.0.4 in the API? I am not sure how you are standing on such changes and whether you've noticed it (I am trying out 2.0.4.BUILD-SNAPSHOT for another issue and noticed it).
Maybe something like:
public interface DispatcherServletPathProvider {
@Deprecated
String getServletPath();
default Set<String> getServletPaths() {
String servletPath = getServletPath();
Set<String> servletPaths = new HashSet<>();
servletPaths.add(servletPath);
return servletPaths;
}
}
Would be more appropriate?
We are only a consumer of this interface (see this) and we can easily change it. However, when people upgrade to 2.0.4 and we don't have a new release in the same time as you then they will have compilation issues
@filiphr You're right, it is a breaking change between 2.0.3 and 2.0.4. However, the DispatcherServletPathProvider was introduced quite recently (in 2.0.2) and we didn't expect that there would be too many consumers of this class. This change originally stemmed from #13527.
I'll reopen the issue to see what the rest of the team thinks.
Thanks for having a look at it. I noticed that it is quite new as well. My usage for it is due to #13183
I think the breaking change is OK as it is fixing a bug in the API. While the default method is a nice non-breaking solution, I don鈥檛 think it is warranted in this case.
Reopened because #12971 is making me reconsider if we should have multiple path support
See also #12934
We're going to roll back support for multiple paths because of the issues identified in #13834
Most helpful comment
I think the breaking change is OK as it is fixing a bug in the API. While the default method is a nice non-breaking solution, I don鈥檛 think it is warranted in this case.