Spring Profiles provide a way to segregate parts of your application configuration and make it only available in certain environments. Any @Component or @Configuration can be marked with @Profile to limit when it is loaded:
Externalized Configuration
Spring Boot allows you to externalize your configuration so you can work with the same application code in different environments. You can use properties files, YAML files, environment variables and command-line arguments to externalize configuration. Property values can be injected directly into your beans using the @Value annotation, accessed via Spring’s Environment abstraction or bound to structured objects via @ConfigurationProperties.
Profile
...
specific properties
In addition to application.properties files
| Include Page |
|---|
| _PropertiesFileJava |
|---|
| _PropertiesFileJava |
|---|
|
files, profile-specific properties can also be defined using the naming convention
application-{profile}.properties.
You are advised to only use lower case filenames and lower case profile names because Spring profile names are case sensitive. The Environment has a set of default profiles (by default [
default]) which are used if no active profiles are set (i.e. if no profiles are explicitly activated then properties from
application-default.properties are loaded).
Profile-specific properties are loaded from the same locations as standard application.properties
| Include Page |
|---|
| _PropertiesFileJava |
|---|
| _PropertiesFileJava |
|---|
|
, with profile-specific files always overriding the non-specific ones irrespective of whether the profile-specific files are inside or outside your packaged jar.
If several profiles are specified, a last wins strategy applies. For example, profiles specified by the spring.profiles.active property are added after those configured via the SpringApplication API and therefore take precedence.
Activating profiles
Spring profiles can be activated via JVM argument spring.profiles.active. When a
| Include Page |
|---|
| _ConfigLocation |
|---|
| _ConfigLocation |
|---|
|
is set the active profiles can also be set by placing a | Include Page |
|---|
| _PropertiesBootstrap |
|---|
| _PropertiesBootstrap |
|---|
|
in the config location directory. The | Include Page |
|---|
| _PropertiesBootstrap |
|---|
| _PropertiesBootstrap |
|---|
|
should then contain the spring.profiles.active property, do not use the two mechanisms (JVM argument and | Include Page |
|---|
| _PropertiesBootstrap |
|---|
| _PropertiesBootstrap |
|---|
|
) at the same time. The application server must be restarted after changing the active Spring profiles.An example
| Include Page |
|---|
| _PropertiesBootstrap |
|---|
| _PropertiesBootstrap |
|---|
|
file:| Code Block |
|---|
| title | bootstrap.properties |
|---|
|
spring.profiles.active=native,development-tools,dashboard,customerdata-client,trace-sql-store,process-sql-store,reporting-sql-store,comments-sql-store,scheduler-quartz
spring.config.location=classpath:/
spring.config.additional-location=
spring.cloud.config.server.native.searchLocations=${spring.config.location},${spring.config.additional-location}
spring.cloud.config.server.bootstrap=true |
| Code Block |
|---|
| language | text |
|---|
| title | Configuration of Spring Profiles |
|---|
| collapse | true |
|---|
|
java -Dspring.profiles.active="native,cmis-client,comments-sql-store,customerdata-sql-store,dashboard,development-tools,managementservice-client,process-sql-store,publisher-client,reporting-sql-store,trace-sql-store" -Dspring.config.location="%~dp0/Runtime/Java/conf/" -jar Runtime/Java/bin/blueriq-runtime-standalone.jar
|
File System Backend
There is also a "native" profile in the Config Server that doesn’t use Git, but just loads the config files from the local classpath or file system (any static URL you want to point to with "spring.cloud.config.server.native.searchLocations"). To use the native profile just launch the Config Server with "spring.profiles.active=native".
Remember to use the file: prefix for file resources (the default without a prefix is usually the classpath). Just as with any Spring Boot configuration you can embed ${}-style environment placeholders, but remember that absolute paths in Windows require an extra "/", e.g. file:///${user.home}/config-repo
The Config Server runs best as a standalone application, but if you need to you can embed it in another application. Just use the @EnableConfigServer annotation. An optional property that can be useful in this case is spring.cloud.config.server.bootstrap which is a flag to indicate that the server should configure itself from its own remote repository. The flag is off by default because it can delay startup, but when embedded in another application it makes sense to initialize the same way as any other application.
If you want to read the configuration for an application directly from the backend repository (instead of from the config server) that’s basically an embedded config server with no endpoints. You can switch off the endpoints entirely if you don’t use the @EnableConfigServer annotation (just set spring.cloud.config.server.bootstrap=true).
When it runs it will pick up the external configuration from the default local config server on port 8888 if it is running. To modify the startup behaviour behavior you can change the location of the config server using bootstrap.properties (like application.properties but
| Include Page |
|---|
| _PropertiesBootstrap |
|---|
| _PropertiesBootstrap |
|---|
|
(such as | Include Page |
|---|
| _PropertiesFileJava |
|---|
| _PropertiesFileJava |
|---|
|
but for the bootstrap phase of an application context)
, e.g.
...
.
Further reading
http://cloud.spring.io/spring-cloud-config/spring-cloud-config.html
http://docs.spring.io/spring-boot/docs/current/reference/html/boot-features-external-config.html