ResourceUrlProvider detects wrong set of handler mappings #26561
Assignees
Labels
in: web
Issues in web modules (web, webmvc, webflux, websocket)
status: backported
An issue that has been backported to maintenance branches
type: bug
A general bug
Milestone
Comments
spring-projects-issues
added
status: backported
jhoeller
added
the
in: web
This was referenced Mar 16, 2021
This was referenced Mar 17, 2021
Closed
lxbzmy
pushed a commit
to lxbzmy/spring-framework
that referenced
this issue
Mar 26, 2022
Prior to this commit, `ResourceUrlProvider` would listen and consider all `ContextRefreshedEvent` and use the given context to detect `SimpleUrlHandlerMapping`. This could lead to situations where a `ResourceUrlProvider` uses another application context than its own (in a parent/child context setup) and detect the wrong set of handlers. Because `ResourceUrlProvider` locks itself once the auto-detection is done, we need to ensure that it considers only events sent by its application context. Fixes spring-projectsgh-26561
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
See spring-projects/spring-boot#25113 for more context.
ResourceUrlProvideris listening onContextRefreshedEventto detect automatically instances ofSimpleUrlHandlerMappingand use them for writing URLs to resources. Once handlers are detected the provider locks itself from further modifications.With a parent/child context setup and under specific conditions due to ordering, the
ResourceUrlProvidermight receive aContextRefreshedEventfrom a child context first, thus detecting the wrong set of handlers and ignoring the expectedContextRefreshedEventonce all components are ready in the current context.We must ensure that
ResourceUrlProvideronly considers events sent by the current context - this is a common pattern in other parts of Spring Framework.The text was updated successfully, but these errors were encountered: