spring-cloud-aws-parameter-store-config prioritizes default-context parameters over service-specific parameters

Type: Bug

Component: Parameter Store

Describe the bug Spring Cloud Version: 2.3.1 In parameter store we have two parameters with names:

1. /config/application/xxx
2. /config/my-service/xxx

In our spring application.properties we have the following configuration: spring.application.name=my-service

When we start the application it is the parameter from (1.) that is set, even though we would expect (2.) to override the default-context’s parameter. Note: If we change aws.paramstore.default-context to something else than application it will use the value from (2.).

From the description of default-context it says:

Shared by all services that have the Configuration support enabled. Can be overridden with a service- or profile-specific property.

So we would expect (2.) to override (1.), but this is not the case?

[darrelldraney]

@WtfJoke I just ran into this issue when using version 2.3.3 and adding a dependency on spring-cloud-starter-bootstrap as opposed to using the spring.config.import=aws-parameterstore: property like you did in your example project. Reverting to 2.3.2 and using spring-cloud-starter-bootstrap works as expected.

@jmax01 when you ran into this issue with 2.3.3 were you using spring-cloud-starter-bootstrap instead of importing the properties like @WtfJoke does in his example project?

[ericmillinder]

The ordering of locations returned by AwsParamStorePropertySourceLocator does not appear to follow the ascending precedence ordering expected. This looks like it happened way back in https://github.com/spring-cloud/spring-cloud-aws/commit/582fdc6691ead7904aaed176af2cf85221edacd5. The sources have been moved into AwsParamStorePropertySources since then but still maintain a backwards order of precedence. Just look at AwsParamStorePropertySourceLocatorTest and you will see them testing the ordering and it prefers the default context. Maybe this got overlooked after they moved repos?