Getting started in Spring Boot, Part 12 Working with multiple system environments
In software development, it is often necessary to work with multiple environments, such as development or production. Profiles in Spring Boot allow you to quickly switch between the corresponding configurations.
Companies on the topic
Using profiles, Spring makes it quite easy to set the configuration for specific environments. (Image: Kaboompics.com / Pexels )
Different system environments are characterized, for example, by different databases or differences in authentication. For example, low-maintenance in-memory databases are often used during development or logging into the application is automated for the developer due to time constraints. Further differences in the environments could affect connected systems such as LDAP servers or tests with mock objects.
Each of these environments can therefore be fundamentally different and therefore requires a different configuration. In Spring, this configuration affects the properties in application.properties (or application.yml) and on the other hand the configuration of beans.
In practice, of course, you want to switch between the environment configurations as quickly as possible (and not all properties in application.customize properties by hand). It would be desirable to switch to a different properties file and load other beans into the Spring container by setting a single parameter with the name of the environment. No problem, that’s exactly what profiles were created for!
Property files in profiles
Properties were discussed in detail in the previous article in this series. For Spring Boot, the default properties file is called application.properties (or application.yml when using the YAML format) and is located in the folder src / main / resources.
To create an environment-specific variant of the file, append the name of the environment as a hyphen suffix to the application to. Here the file is called application-prod.properties, so the name of the profile is prod. The file simply sets a different port for any Spring Boot application for testing purposes:
server.port=8081
A start of the application after these changes shows that the application is still listening on port 8080. The log messages also indicate that the new profile is not yet used (“No active profile set, falling back to default profiles: default”).
Spring obviously has to be told that the new profile should also be used. There are various options for this, for example, the profile can be selected in the Spring Tool Suite (STS) in the Run configuration.
The profiles can be selected and adapted in the Run Configurations.
(Picture: Koller / Spring)
After starting with the prod profile, the application is now accessible under port 8081 and the desired profile is also displayed in the log prod spent.
Application.properties (without suffix) remains in src / main / resources get. Properties configured only there are still used. If properties are specified in the environment-specific files, then they are dragged. Properties can thus be virtually overwritten.
Beans in profiles
Beans can be annotated with @Profile with the name of the environment in which they should be active. In the following example, a class named DevPersister for the profile dev unconfigured:
@Configuration
@Profile("dev")
public class DevPersister { @Bean
public Persister databasePersister() {
return new DatabasePersister(DBType.Dev);
}
}
This configuration is only loaded into the Spring container when using the dev profile. The same configuration of a class for the profile prod looks like this:
@Configuration
@Profile("prod")
public class ProdPersister { @Bean
public Persister databasePersister() {
return new DatabasePersister(DBType.Prod);
}
}
Depending on the activated profile, one or the other class can be found in the container and the class will be Data base persister either configured for development or for production (here only indicated by the parameter in the constructor).
The class in the example is annotated with @Configuration. @Profiles can be used in configurations and all components (including controllers, Services and Repositories).
With the Not operator (!) a bean can also be specifically deactivated in a specific profile. The bean is then present in all other profiles:
@Profile("!dev")
In addition, it is possible to qualify a Bean for multiple Profiles, these are listed separated by commas :
@Profile("dev", "prod")
Enable profiles
There are several ways to activate a profile. Which one is chosen depends on the type of application and the environment in which it is run. The selection of the profile in the STS configuration has already been shown above. During development, this is a simple and viable Option.
It is also possible to view the active profile in a property in application.to set properties, it is called spring.profile.active:
spring.profiles.active=dev
Or you pass the profile name as JVM system parameter at the start of the application:
java -Dspring.profiles.active=dev -jar DemoApplication.jar
This variant has the advantage that the application files no longer need to be touched, and therefore offers itself on the production machine. There are other methods such as programmatic registration of profiles or the use of the annotation _@ActiveProfiles_ in tests, which are mentioned here only for the sake of completeness.
Spring profiles are perfect for working with different environments and hardly any enterprise application with connected subsystems can do without them. However, the application can also be adapted for different customers, clients or brands.
One quickly comes to the thought that possibly also different languages can be realized with it. However, there is a separate solution for this, which will be presented in one of the next articles.
(ID:47331416)
