aws paramstore with multiple active profiles

[jaroslaw-blazkow]

Hi, I'm trying to migrate to the newest awspring libraries, but I cannot find solution for the new approach with specifying paramstore variables.
I've tried to use
spring.config.import: "aws-parameterstore:" in bootstrap.yml but it seems its not longer supported with default resolvers with aws.parameterstore.separator, etc. and left unbound, so I found out this solution:

spring:
  config:
    import:
      - aws-parameterstore:/config/app_${spring.profiles.active}

but the problem is, that I've got couple profiles active. How to solve it?

[evangaito]

I'm also running into this issue. Profile-based parameter retrieval has been severely neutered in 3.x. There seems to be no way to use spring profiles in parameter retrieval unless you ensure that there's only one active profile at a time. When multiple profiles are active, Spring interprets everything after the comma as a separate config location with no prefix. I assume that the maintainers of this project did not expect users to use spring.profiles.active in the config import string but did not give us any alternatives. I'm in the middle of upgrading right now and I think this issue is going to make me stay on 2.x.

Editing to clarify:
Spring splits the config string into multiple locations when you only import a single string like this:

spring:
  config:
    import: "aws-parameterstore:/config/app_${spring.profiles.active}/"

Lets say I'm running the application with active profiles "foo, bar". In the preceding example Spring will try two imports:

• aws-parameterstore:/config/app_foo (this works, except the trailing slash is lost)
• bar/ (this doesn't)

If you put the import in an array like in the original comment it won't split it.

spring:
  config:
    import: 
      - "aws-parameterstore:/config/app_${spring.profiles.active}/"

That results in a single string that includes both profiles in the request to SSM, aws-parameterstore:/config/app_foo, bar/.

[maciejwalkowiak]

Sorry to hear that changes we introduced give you hard times with upgrading. I'll take another look into how other projects handle profile specific spring.config.import. In meantime, you do not have to stay on 2.x - you can always provide your own implementation of config import that will respect active profiles.