Repository navigation
Profile not correct with SpringBoot 2.4.1 + Ilford 2020.0.0 (working with 2.4.1 + Ilford 2020.0.0-RC1) #1777
Description
Hello Spring Cloud Config Team,
Maybe a small bug with Ilford 2020.0.0 and SpringBoot 2.4.1
With a web app, 2.4.1 + Ilford 2020.0.0-RC1, the properties are being picked up correctly at client side.
When the client starts, I do see below logs, very happy 😃
[ main] c.a.Application : The following profiles are active: my-env
[ main] o.s.b.context.config.ConfigDataLoader : Fetching config from server at : https://my-service/config
[ main] o.s.b.context.config.ConfigDataLoader : Located environment: name=myservice, profiles=[my-env], label=null, version=7f95facc49b97272a0a3915650b12e56ea7440bf, state=null
[ main] c.u.j.EncryptablePropertySourceConverter : Converting PropertySource configserver:https://my-git/myservice-my-env.properties [org.springframework.boot.env.OriginTrackedMapPropertySource] to EncryptableMapPropertySourceWrapper
note profiles=[my-env]
However, same code, just one change, Ilford 2020.0.0-RC1 -> Ilford 2020.0.0, the properties are not being picked up.
On startup, I am seeing the following instead:
[ main] c.a.Application : The following profiles are active: my-env
[ main] o.s.b.context.config.ConfigDataLoader : Fetching config from server at : https://my-service/config
[ main] o.s.b.context.config.ConfigDataLoader : Located environment: name=myservice, profiles=[default], label=null, version=7f95facc49b97272a0a3915650b12e56ea7440bf, state=null
[ main] c.u.j.EncryptablePropertySourceConverter : Converting PropertySource Config resource 'class path resource [application.properties]' via location 'optional:classpath:/' [org.springframework.boot.env.OriginTrackedMapPropertySource] to EncryptableMapPropertySourceWrapper
And then again reverted back to 2020.0.0-RC1, and working.
May I ask what is the root cause of this issue please?
Thank you
Reacted by dnijssen, Yusuf Kemal Özcan, Diego Magdaleno and Islam Hassan
Activity
dnijssen commentedon Dec 23, 2020
I just encountered the same issue, and created a reproduction path for @spencergibb and his team -> https://github.com/dnijssen/config-server-client . Seems to be a regression issue to me, as I can confirm it did indeed work with
2020.0.0-RC1spencergibb commentedon Dec 23, 2020
As a workaround to get the config client to send the right profile, set
spring.cloud.config.profileto the same values asspring.profiles.active.spencergibb commentedon Dec 23, 2020
There is a second issue in config server where the names of the property sources are the same, so
Defaultstill gets returned because the correct property source gets overridden.{ "name": "config-client", "profiles": [ "test" ], "label": null, "version": null, "state": null, "propertySources": [ { "name": "class path resource [config/config-client.yaml", "source": { "spring.config.activate.on-profile": "test", "config-client.test": "Test" } }, { "name": "class path resource [config/config-client.yaml", "source": { "config-client.test": "Default" } } ] }dnijssen commentedon Dec 23, 2020
Ty for the workaround! I can indeed confirm the second issue as well :) Would you be able to convert that one into a seperate issue yourself? As you might be able better to describe it.
ncioj10 commentedon Jan 8, 2021
Where to apply these workarounds? To me it seems that the configserver pull is completely broken. For me it doesn't even work with legacy processing. It just doesn't pull the files with in application.properties and bootstrap.properties.
The documentation is very confusing regarding this, it would be good to have that in a central place as currently it is not clear how to upgrade.
spencergibb commentedon Jan 11, 2021
They have been fixed in version 3.0.1 see https://github.com/spring-cloud/spring-cloud-release/wiki/Spring-Cloud-2020.0-Release-Notes#known-issues
Only use spring.cloud.config.profiles if not 'default'.