Prior to this commit, if a @ControllerAdvice bean implemented both
RequestBodyAdvice and ResponseBodyAdvice, it was registered twice in
RequestMappingHandlerAdapter, leading to duplicate application of the
same logic.
This commit ensures that such instances are only registered once.
Fixes gh-22638
Prior to this commit, if a @ControllerAdvice bean implemented both
RequestBodyAdvice and ResponseBodyAdvice, it was only supported as
RequestBodyAdvice, meaning it was never invoked as ResponseBodyAdvice.
This commit revises RequestResponseBodyAdviceChain to ensure that a
single bean implementing both types of body advice is in fact handled
as both types of advice.
See gh-22638
Prior to this commit, the `ResourceUrlEncodingFilter` would wrap the
response and keep a reference to the request. When
`HttpServletResponse.encodeURL` is later called during view rendering,
the filter looks at the request and extracts context mapping information
in order to resolve resource paths in views.
This approach is flawed, when the filter is used with JSPs - if the
request is forwarded to the container by the `InternalResourceView`,
the request information is overwritten by the container. When the view
is being rendered, the information available in the request is outdated
and does not allow to correctly compute that context mapping
information.
This commit ensures that that information is being extracted from the
request as soon as the `ResourceUrlProvider` is set as a request
attribute.
Issue: SPR-17421
(Cherry-picked from cf25efc7d3)
The fix for SPR-17178 switched from debug to warn level warning for
all sub-classes of AbstractHandlerExceptionResolver where the request
concerned the DefaultHandlerExceptionResolver only.
This commit restores the original DEBUG level logging that was in
AbstractHandlerExceptionResolver from before SPR-17178. In addition
DefaultHandlerExceptionResolver registers a warnLogCategory by default
which enables warn logging and hence fulfilling the original goal
for SPR-17178.
Issue: SPR-17383