Configuring with profiles
Based on the environment some configuration gets changed. A profile based configuration can be activated for the respective environment using the @profile.
Example:
@Profile("production")
@Configuration
@EnableWebSecurity
public class SecurityConfig extends WebSecurityConfigurerAdapter { }
The @Profile annotation used here requires that the “production” profile be active at runtime for this SecurityConfig configuration to be applied. If the “production” profile isn’t active, this configuration will be ignored Profiles can be activated by setting the spring.profiles.active property using any of the means available for setting any other configuration property
PROFILE-SPECIFIC PROPERTIES FILES
you can provide profile-specific properties by creating additional properties files named with
the pattern “application-{profile}.properties”.
For the logging scenario, the development configuration would be in a file named application-development.properties and contain properties for verbose, console written logging:
logging.level.root=DEBUG
For production, application-production.properties would configure logging to be at WARN level and higher and to write to a log file:
logging.path=/var/logs/
logging.file=BookWorm.log
logging.level.root=WARN
Any properties that aren’t specific to any profile can continue to be expressed in application.properties:
amazon.associateId=habuma-20
logging.level.root=INFO
If you’re using YAML for configuration properties, you can follow a similar naming convention as for properties files. That is, you can create YAML files whose names follow a pattern of “application-{profile}.yml” and continue to put non-profiled properties in application.yml.
With YAML, you also have the option of expressing configuration properties for all profiles in a single application.yml file like this:
Logging:
Level:
root: INFO
---
Spring:
profiles: development
Logging:
Level:
root: DEBUG
---
Spring:
profiles: production
Logging:
path: /tmp/
file: BookWorm.log
Level:
root: WARN