Page History

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 Blueriq uses Spring Boot's Externalised Configuration feature to allow you to externalize configuration which allows to use the same Blueriq code in different environments. Further, all Blueriq application configuration is divided into Spring Profile's to be able to selectively make code available. Each profile makes use of it's own proprtyfile, 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-<PROFILENAME>.properties

Currently, the following profiles exist in Blueriq:

bootstrap.properties

Spring provides a couple of ways to externalize application configuration. Blueriq makes use of the possibility to pick up application configuration from the classpath. To tell Spring to pick up configuration from the classpath we need to configure the bootstrap.properties as follows:

{profile}.properties. 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.

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

spring.profiles.active=native,dev

spring.cloud.config.server.native.searchLocations=file:${spring.config.location:.}

Spring's predefined "native" profile

"native" is one of Spring's predefined profiles that needs to be configured to be able to load the config files from the local classpath or file system.

).

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 you can change the location of the config server using bootstrap.properties (like application.properties but for the bootstrap phase of an application context), e.g.

https://tools.blueriq.com/confluence/display/TEC/Spring+Cloud+Config
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