You are viewing the documentation for Blueriq 17. Documentation for other versions is available in our documentation directory.
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, 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, 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
spring.config.additional-locationbootstrap.properties in the config location directory. The bootstrap.properties should then contain the spring.profiles.active property, do not use the two mechanisms (JVM argument and bootstrap.properties) at the same time. The application server must be restarted after changing the active Spring profiles.An example bootstrap.properties file:
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
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 behavior you can change the location of the config server using bootstrap.properties (such as application.properties but for the bootstrap phase of an application context).
Further reading
- Blueriq's Spring Profiles
- External datasources configuration
- How to enable the dev plugin
- How to make use of profile specific configuration
- Spring's 'native' profile
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
Overview
Content Tools