[
https://issues.apache.org/jira/browse/CAMEL-24532?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Federico Mariani updated CAMEL-24532:
-------------------------------------
Description:
*Problem*
The early-resolution listeners iterate Spring {{PropertySources}} in precedence
order (highest first) and collect resolved values in one flat {{Properties}}
object. When the same key is a matching placeholder in more than one source,
each subsequent write replaces the previous value. The resulting property
source is then added with {{addFirst}}, so the value originally taken from the
lowest-precedence matching source wins.
*Reproduction*
Define the same property as an early-resolved placeholder in
{{application.properties}} and in a higher-precedence profile-specific source
such as {{application-prod.properties}}. With early resolution enabled, the
parser resolves both entries but the resolved value from
{{application.properties}} becomes effective, instead of the profile-specific
value.
*Expected behaviour*
Early resolution must preserve Spring's normal precedence: the
highest-precedence matching property source supplies the effective resolved
value.
*Suggested direction*
Process sources in reverse when populating the flat override map, or otherwise
retain the first value seen while iterating in precedence order. Add a
regression test that covers duplicate keys across property sources.
was:
h2 Problem
The early-resolution listeners iterate Spring {{PropertySources}} in precedence
order (highest first) and collect resolved values in one flat {{Properties}}
object. When the same key is a matching placeholder in more than one source,
each subsequent write replaces the previous value. The resulting property
source is then added with {{addFirst}}, so the value originally taken from the
lowest-precedence matching source wins.
h2 Reproduction
Define the same property as an early-resolved placeholder in
{{application.properties}} and in a higher-precedence profile-specific source
such as {{application-prod.properties}}. With early resolution enabled, the
parser resolves both entries but the resolved value from
{{application.properties}} becomes effective, instead of the profile-specific
value.
h2 Expected behaviour
Early resolution must preserve Spring's normal precedence: the
highest-precedence matching property source supplies the effective resolved
value.
h2 Suggested direction
Process sources in reverse when populating the flat override map, or otherwise
retain the first value seen while iterating in precedence order. Add a
regression test that covers duplicate keys across property sources.
h2 Context
The issue was identified and verified while reviewing
https://github.com/apache/camel-spring-boot/pull/1900. The current HashiCorp
implementation demonstrates the pattern:
https://github.com/apache/camel-spring-boot/blob/82f0eaf18a4047624f457847e7ce883d0e0ed7a9/components-starter/camel-hashicorp-vault-starter/src/main/java/org/apache/camel/component/hashicorp/vault/springboot/SpringBootHashicorpVaultPropertiesParser.java#L65-L93.
Original review discussion:
https://github.com/apache/camel-spring-boot/pull/1900#issuecomment-5441526018.
_Created by Codex on behalf of Federico Mariani._
> Camel Spring Boot: Preserve property-source precedence during early vault
> resolution
> ------------------------------------------------------------------------------------
>
> Key: CAMEL-24532
> URL: https://issues.apache.org/jira/browse/CAMEL-24532
> Project: Camel
> Issue Type: Bug
> Reporter: Federico Mariani
> Priority: Major
>
> *Problem*
> The early-resolution listeners iterate Spring {{PropertySources}} in
> precedence order (highest first) and collect resolved values in one flat
> {{Properties}} object. When the same key is a matching placeholder in more
> than one source, each subsequent write replaces the previous value. The
> resulting property source is then added with {{addFirst}}, so the value
> originally taken from the lowest-precedence matching source wins.
> *Reproduction*
> Define the same property as an early-resolved placeholder in
> {{application.properties}} and in a higher-precedence profile-specific source
> such as {{application-prod.properties}}. With early resolution enabled, the
> parser resolves both entries but the resolved value from
> {{application.properties}} becomes effective, instead of the profile-specific
> value.
> *Expected behaviour*
> Early resolution must preserve Spring's normal precedence: the
> highest-precedence matching property source supplies the effective resolved
> value.
> *Suggested direction*
> Process sources in reverse when populating the flat override map, or
> otherwise retain the first value seen while iterating in precedence order.
> Add a regression test that covers duplicate keys across property sources.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
