Fallback with placeholder is evaluated even if the fallback is not required #26268
Comments
|
This is standard behaviour for Spring Framework's I'm not aware of the reasons behind the default value being processed in full before it's then discarded. On the face of it, it feels less efficient than it could be, but there may well be something that I've overlooked. We'll get the Framework team to take a look. |
spring-projects-issues
added
the
status: waiting-for-triage
|
Great, I did a quick workaround of setting empty in nested env variable and checked it myself in the code, but it doesn't feel like an intuitive behavior. Thanks |
rstoyanchev
added
the
in: core
snicoll
changed the title
snicoll
added
type: bug
|
That looks like a bug to me and I wish we'd resolve the fallback lazily. I'll see what we can do. |
|
Unfortunately, fixing it goes in the direction of rewriting the parser for supporting the escape of placeholder and separator. This is ongoing but need a new feature release, see #9628 |
This commit provides a rewrite of the parser for properties containing
potentially placeholders.
Assuming a source where `firstName` = `John` and `lastName` = `Smith`,
the "${firstName}-${lastName}" property is evaluated as "John-Smith".
Compared with the existing implementation in PropertyPlaceholderHelper,
the new implementation offers the following extra features:
1. Placeholder can be escaped using a configurable escape character.
When a placeholder is escaped it is rendered as is. This does apply to
any nested placeholder that wouldn't be escaped. For instance,
"\${firstName}" is evaluated as "${firstName}".
2. The default separator can also be escaped the same way. When the
separator is escaped, the left and right parts are not considered as
the key and the default value respectively. Rather the two parts
combined, including the separator (but not the escape separator) are
used for resolution. For instance, ${java\:comp/env/test} is looking
for a "java:comp/env/test" property.
3. Placeholders are resolved lazily. Previously, all nested placeholders
were resolved before considering if a separator was present. This
implementation only attempts the resolution of the default value if the
key does not provide a value.
4. Failure to resolve a placeholder are more rich, with a dedicated
PlaceholderResolutionException that contains the resolution chain.
See spring-projectsgh-9628
See spring-projectsgh-26268
This commit provides a rewrite of the parser for properties containing
potentially placeholders.
Assuming a source where `firstName` = `John` and `lastName` = `Smith`,
the "${firstName}-${lastName}" property is evaluated as "John-Smith".
Compared with the existing implementation in PropertyPlaceholderHelper,
the new implementation offers the following extra features:
1. Placeholder can be escaped using a configurable escape character.
When a placeholder is escaped it is rendered as is. This does apply to
any nested placeholder that wouldn't be escaped. For instance,
"\${firstName}" is evaluated as "${firstName}".
2. The default separator can also be escaped the same way. When the
separator is escaped, the left and right parts are not considered as
the key and the default value respectively. Rather the two parts
combined, including the separator (but not the escape separator) are
used for resolution. For instance, ${java\:comp/env/test} is looking
for a "java:comp/env/test" property.
3. Placeholders are resolved lazily. Previously, all nested placeholders
were resolved before considering if a separator was present. This
implementation only attempts the resolution of the default value if the
key does not provide a value.
4. Failure to resolve a placeholder are more rich, with a dedicated
PlaceholderResolutionException that contains the resolution chain.
See gh-9628
See gh-26268
Hello all,
used spring boot: 2.2.1.RELEASE
Problem: When defining application.yml properties I want to use something like:
property: ${FOO:someFallbackWithEnv_${BAR}}
someOtherProperty: ${property}
With
@ConfigurationPropertiesit works as expected but with injection via@Valueor in application.yml (someOtherProperty) it fails with "could not resolve BAR". I think it is not expected as FOO was defined as env variable so the other part should not be processed at all IMO.The text was updated successfully, but these errors were encountered: