Spring-boot: spring.profiles.include does not seem to be picked up in JBoss 6.3 system properties

Created on 23 Sep 2015  路  4Comments  路  Source: spring-projects/spring-boot

In the JBoss 6.3 management console it's possible to set system properties.

If we set spring.profiles.active to foo, then any application-foo.properties file gets picked up.

If we set spring.profiles.include to foo, it does not read the application-foo.properties file.

If we set .include to foo and .active to bar (ie, show the compounding of profiles), then it does not read the application-foo.properties file.

We have not tested with the embedded Tomcat or in other environments.

duplicate

Most helpful comment

I can confirm that spring.profiles.include is not effective when provided as an environment variable to the embedded Tomcat. Our use case is similar: We want to allow a certain level of freedom when it comes to what profiles are available, but a few should always be enabled.

PS: I realize this is not the intended use of spring.profiles.include, but it sure would be nice if it worked this way, similar to spring.profiles.active, which can be specified as an environment variable.

All 4 comments

That behavior is somewhat expected (although probably not documented that well and perhaps should be refined). The spring.profiles.include property is intended to be used inside an existing property file, i.e:

--spring.profiles.active=bar

# application-bar.properties
spring.profiles.include=foo

Is there any reason that you need to use spring.profiles.include?

Is there any reason that you need to use spring.profiles.include?

Paranoia.

I don't have much insight into the final production container's configuration. But I do know that setting system properties is container-wide, so if we set spring.profiles.active, we set it for all WARs on that server.

I can confirm that spring.profiles.include is not effective when provided as an environment variable to the embedded Tomcat. Our use case is similar: We want to allow a certain level of freedom when it comes to what profiles are available, but a few should always be enabled.

PS: I realize this is not the intended use of spring.profiles.include, but it sure would be nice if it worked this way, similar to spring.profiles.active, which can be specified as an environment variable.

duplicates #7668

Was this page helpful?
0 / 5 - 0 ratings