Application- and profile-specific configuration usage - undocumented or not meant to be used?

[filpano]

We are currently using a feature of the Spring Cloud Config server that I find quite neat, which is using an application- and profile-specific .yml file on the Config server side that is named ${spring.application.name}-<profile>.yml.

This is allowed through the use of the:

@RequestMapping(path = "/{name}/{profiles}/{label:.*}",
		produces = EnvironmentMediaType.V2_JSON)
public Environment labelledIncludeOrigin(@PathVariable String name,
		@PathVariable String profiles, @PathVariable String label) {
	return getEnvironment(name, profiles, label, true);
}

endpoint. This feature allows some very nice configuration setups (e.g. separate DataSource properties for separate applications, neatly separated from each other). So, for example:

config/
    application.yml                     # Standard properties
    application-${profile}.yml          # Profile relevant settings
    book-service.yml                    # Standard properties for "book-service" only
    book-service-${profile}.yml         # Profile-specific settings for "book-service" only

However, I cannot find any documentation for this feature. Seeing how the endpoint exists, I am assuming that it was meant to be used. Is this a documentation oversight (which I can gladly make a PR for), or was there an intention to deprecate this endpoint at some time?

[filpano]

According to these two:

https://github.com/spring-cloud/spring-cloud-config/issues/1856#issuecomment-820528524 https://github.com/spring-cloud/spring-cloud-config/issues/1856#issuecomment-820541005

comments, it seems this is a indeed a supported feature. I'll get a PR to enhance the documentation up within the next few days.

[ChiragMoradiya]

I needed to validate behavior to understand which one is given more preference than other. My finding is as follows:

Configurations are used in the following orders:

• book-service-${profile}.yml
• application-${profile}.yml
• book-service.yml
• application.yml

So, when the configuration property is available in book-service-${profile}.yml it's used at the top priority. If it doesn't exist there, then application-${profile}.yml is searched, and so on.