Escaped placeholders are evaluated if the PropertySource has placeholder support #34326
Assignees
Labels
in: core
Issues in core modules (aop, beans, core, context, expression)
status: superseded
An issue that has been superseded by another
type: bug
A general bug
Comments
|
So the problem is that The problem is that this resolved value come back to the original parser. Rather than seeing |
sbrannen
added a commit
to sbrannen/spring-framework
that referenced
this issue
May 10, 2025
Currently, the placeholder resolution algorithm in PropertySourcesPlaceholderConfigurer fails in several scenarios, and the root cause for this category of failures has actually existed since PropertySourcesPlaceholderConfigurer was introduced in Spring Framework 3.1. Specifically, PropertySourcesPlaceholderConfigurer creates its own PropertySourcesPropertyResolver that indirectly delegates to another "nested" PropertySourcesPropertyResolver to interact with PropertySources from the Environment, which results in double placeholder parsing and resolution attempts, and that behavior leads to a whole category of bugs. For example, spring-projects#27947 was addressed in Spring Framework 5.3.16, and due to spring-projects#34315 and spring-projects#34326 we have recently realized that additional bugs exist with placeholder resolution: nested placeholder resolution can fail when escape characters are used, and it is currently impossible to disable the escape character support for nested resolution. To address this category of bugs, we no longer indirectly use or directly create a "nested" PropertySourcesPropertyResolver in PropertySourcesPlaceholderConfigurer. Instead, properties from property sources from the Environment are now accessed directly without duplicate/nested placeholder resolution. See spring-projectsgh-27947 See spring-projectsgh-34326 See spring-projectsgh-34862 Closes spring-projectsgh-34861
sbrannen
added a commit
that referenced
this issue
May 10, 2025
Currently, the placeholder resolution algorithm in PropertySourcesPlaceholderConfigurer fails in several scenarios, and the root cause for this category of failures has actually existed since PropertySourcesPlaceholderConfigurer was introduced in Spring Framework 3.1. Specifically, PropertySourcesPlaceholderConfigurer creates its own PropertySourcesPropertyResolver that indirectly delegates to another "nested" PropertySourcesPropertyResolver to interact with PropertySources from the Environment, which results in double placeholder parsing and resolution attempts, and that behavior leads to a whole category of bugs. For example, #27947 was addressed in Spring Framework 5.3.16, and due to #34315 and #34326 we have recently realized that additional bugs exist with placeholder resolution: nested placeholder resolution can fail when escape characters are used, and it is currently impossible to disable the escape character support for nested resolution. To address this category of bugs, we no longer indirectly use or directly create a "nested" PropertySourcesPropertyResolver in PropertySourcesPlaceholderConfigurer. Instead, properties from property sources from the Environment are now accessed directly without duplicate/nested placeholder resolution. See gh-27947 See gh-34326 See gh-34862 Closes gh-34861
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
This is a follow-up of #34315
Consider the following example:
prop2should evaluate tovalue2${prop1}as the placeholder has been escaped.This works for basic
PropertySourceimplementations, but if the source is backed byPropertySourcesPlaceholderConfigurerthe escaped${prop1}is still evaluated even though it should not be.The text was updated successfully, but these errors were encountered: