Affects: \
After Spring commit by default all interceptors will applied to static resource which result in pollute application's log a lot by un-related interceptors warnings.
In resourceHandlerMapping the API provided to override is addResourceHandlers. Since registry.getHandlerMapping() is protected method there is no way to override default behavior, such like override setInterceptors().
Is there any concern about why don't make getHandlerMapping() as public method and enable users override the default behavior?
Comment From: rstoyanchev
Yes, the public methods in ResourceHandlerRegistry are for use by applications. The protected methods are for internal use to complete the registration. In other words, when using code completion, the protected methods are intentionally not visible.
I'm not sure what kind of warnings are created by interceptors and whether that logging could be updated, but one extra option might be to register interceptors with include/exclude path patterns.
Comment From: hangdong123
Hi Rossen, Thanks for response.
Let's assume we have multiple custom interceptors and for interceptor type validation we have warns like: ' Skipping XXX interceptor as ResourceHttpRequestHandler ["/resources/"] is not an instance of HandlerMethod' After mentioned Spring change all these warns pop up complain about static resources and result in pollute our log file.
but one extra option might be to register interceptors with include/exclude path patterns.
Yeah that can be a solution, which means lots of customer side changes to exclude the static path in interceptors one by one. If any web framework built on Spring and have some framework level interceptors, that will introduce PITA to manage all the exclude paths for application owners and framework owners.
AFAIK expose getHandlerMapping() as public method could be the easiest way to enable application owner manage the behavior themselves. I don't know if there is any concern about expose it or any better way?
Comment From: rstoyanchev
The concern, once again, is that if we make that method public, it would become visible on code completion when using ResourceHandlerRegistry and it is not relevant to see there. It's for internal use after the application has used it and is not meant to be visible. It's also not the only such method. If we change this we'd have to be open to do the same for many others across WebMvcConfigurer and that pollutes the API space.
Encountering a non-HandlerMethod in an interrceptor sounds like a debug or even trace message. Not sure why it merits a warning, but if you want to keep it that way, you can fine-tune to exclude ResourceHttpRequestHandler.