Most applications use properties as variables or parameters that have been extracted from the main logic and injected into the application at runtime. Traditionally, these properties existed in files deployed to the server.

One application of Spring Boot is the Profile feature, which allows developers to place related properties and their values into application properties files, thus allowing deployment scripts to refer to the logical groupings of properties with a single environment variable reference at runtime, which greatly simplifies the application.

In this blog, I’ll provide an introduction to Spring Boot Profiles, showing Profiles in action with tangible code examples.

The Need

Properties are typically used by applications as external configuration to control behavior, enable features, provide resources, and vary outcomes as needed. At Runtime, the property values are injected into the application with an intention that the properties will provide resources and control the execution path of the application.

For example, say our properties are job.daily and job.weekly. Let’s also say that their values can be either true or false.

A daily process may require:

job.daily=true

job.weekly=false

A weekly process in the same application may require:

job.daily=false

job.weekly=true

This could easily morph into a solution with multiple property files or a less-than-desirable defaulting strategy, either of which may become difficult to maintain.

Spring Boot Profile Example

Spring Profiles come to the rescue in a case like this, providing a way to segregate parts of your application configuration, making it available only in certain environments. The approach is to bundle relevant properties together into local property files to be used at runtime.

Continuing our example, let’s see that Spring Boot Profile in action.

A property placeholder bean is used to tell Spring the location of the property files. In this example, they are under in classpath.

<beans profile="local"> <context:property-placeholder location="classpath:application-local.properties" /> </beans>

So, in our implementation, under src/main/resources/config , we have application-daily.properies and application-weekly.properties.

1) application-daily.properties contains:

job.daily=true

job.weekly=false

2) application-weekly.properties contains:

job.daily=false

job.weekly=true

Notice that daily and weekly have been substituted for “local” from the bean’s profile configuration.

Now, at runtime, the daily or weekly profile is injected into the application as an environment variable, and the appropriate property values are utilized.

In the below runDailyJob , we are using the daily profile, application-daily.properties by specifying environment variable env[2]=“-Dspring.profiles.active=daily” .

function runDailyJob { local -a [email protected] env[0]="-Dsystem.ecs.version=$CONFIG" env[1]="-Dsystem.ccmr.environment=$ENV" env[2]="-Dspring.profiles.active=daily" env=("${env[@]}" $args) nohup $JAVA_HOME/bin/java -Xmx4096m "${env[@]}" -jar $JAR >/dev/null 2>&1 & }

The next example is using the weekly profile, env[2]="-Dspring.profiles.active=weekly" .

function runWeeklyJob { local -a [email protected] env[0]="-Dsystem.ecs.version=$CONFIG" env[1]="-Dsystem.ccmr.environment=$ENV" env[2]="-Dspring.profiles.active=weekly" env=("${env[@]}" $args) nohup $JAVA_HOME/bin/java -Xmx4096m "${env[@]}" -jar $JAR >/dev/null 2>&1 & }

At this point, your property file can have one set of properties with system default, and each job instance that executes it can have its own set of properties injected at runtime. In our example, each of our jobs, application-daily.properties and application-weekly.properties , have bundled the necessary properties for their own particular job instance.

Final Thoughts

Spring Profiles provides an efficient way to bundle properties according to functionality, thus freeing the Developer from the tedium of other solutions to problem solve a growing set of application properties.

For more information on Spring Profiles, see the official documentation.

Having clean, reliable configuration allows developers to focus on solving development issues, and Spring Profiles provides that freedom. Configure once and run on demand with repeatable, predictable results. That’s a great way to roll.