Recently we were introduced with the concept of Spring Profiles.
This concept is an easy configuration differentiator for different deployment environments.
The straight forward use case (which was presented) was to annotate the relevant classes so Spring would load the appropriate class according to the active profile.
However, this approach might not always serve the common use case... often, the configuration keys would be the same and only the values will change per environment.
In this post, I would like to present a pattern to support loading configuration data per environment, without the need to create/maintain multiple classes for each profile (i.e. for each environment).
Throughout the post I would take the DB connection configuration as a sample, assuming we have different DB definitions (e.g. username or connection URL) for each deployment environment.
The main idea is to use one class for loading the configuration (i.e.. one class for DB connection definition) and inject into it the appropriate instance which holds the correct profile configuration data.
For convenience and clarity, the process was divided into 3 phases:
Phase 1: infra preparation
Step 1.1 - create a properties file which contains all configuration data
Step 1.2 - create an annotation for each profile
step 1.3 - make sure the profile is loaded during context loading
Phase 2: implementing the profile pattern
Step 2.1 - create a properties interface
Step 2.2 - create a class for each profile
Step 2.3 - create an abstract file which holds the entire data
Phase 3: using the pattern
Step 3.1 - example for using the pattern
next part >>