-
Notifications
You must be signed in to change notification settings - Fork 38.4k
IllegalArgumentException due to lack of a cached lookupPath #26546
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Milestone
Comments
@rstoyanchev Just FYI. Having got through out Servlet-build glitch I just ran the reproducer against 5.3.5-SNAPSHOT and all is good. (We knew it would but but....) |
@rodwiddowson thanks for checking. The fix is in 5.3.4. You should be able to use that. It is already out. |
This was referenced Mar 7, 2021
Merged
This was referenced Mar 14, 2021
This was referenced Mar 15, 2021
Open
lxbzmy
pushed a commit
to lxbzmy/spring-framework
that referenced
this issue
Mar 26, 2022
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
After the changes to support parsed
PathPattern
in #24945, various components such asMappedInterceptor
,UrlBasedCorsConfigurationSource
and others expect to find a pre-resolved, cached lookupPath viaServletRequestPathUtils.getCachedPath
. This is done for sub-classes forAbstratHandlerMethodMapping
andAbstractUrlHandlerMapping
but others that extend directly fromAbstractHandlerMapping
would need to callinitLookupPath
in order forMappedInterceptor
and others to find the lookupPath.This is the case with
FlowHandlerMapping
in Spring Web Flow, reported in SWF-1744, which does not need the lookupPath itself but nevertheless that still breaks auxiliary components likeMappedInterceptor
. We can address this inAbstractHandlerMapping#getHandlerExecution
to ensure the presence of a cached lookupPath if not already added by sub-classed ingetHandlerInternal
.The text was updated successfully, but these errors were encountered: