Profile-based configuration in Spring Boot - Step-by-Step Execution

Concept Flow - Profile-based configuration

Start Application

↓

Check Active Profiles

↓

Load application.properties

↓

Load profile-specific properties

↓

Override common properties with profile ones

↓

Initialize Beans with final config

↓

Application runs with profile config

Spring Boot starts, checks which profile is active, loads common and profile-specific settings, then runs with the combined configuration.

Execution Sample

Spring Boot

spring.profiles.active=dev

# application.properties
app.name=MyApp

# application-dev.properties
app.name=MyApp-Dev

This example shows how Spring Boot loads common and dev profile properties, overriding app.name for dev.

Execution Table

Step	Action	Profile Active	Properties Loaded	Resulting app.name
1	Start application	none	application.properties	MyApp
2	Set active profile to dev	dev	application.properties + application-dev.properties	MyApp-Dev
3	Initialize beans with properties	dev	final combined properties	MyApp-Dev
4	Application runs	dev	final combined properties	MyApp-Dev

💡 Application runs with dev profile properties overriding common ones

Variable Tracker

Variable	Start	After Step 1	After Step 2	Final
spring.profiles.active	none	none	dev	dev
app.name	undefined	MyApp	MyApp-Dev	MyApp-Dev

Key Moments - 2 Insights

Why does app.name change after setting the active profile?

Because after Step 2, Spring Boot loads application-dev.properties which overrides app.name from the common application.properties, as shown in the execution_table rows 2 and 3.

What happens if no profile is active?

Only application.properties is loaded, so app.name stays as MyApp, as seen in Step 1 of the execution_table.

Visual Quiz - 3 Questions

Look at the execution_table, what is the value of app.name after Step 1?

A MyApp-Dev

B undefined

C MyApp

D dev

💡 Hint

Check the 'Resulting app.name' column at Step 1 in the execution_table.

At which step does spring.profiles.active become 'dev'?

A Step 2

B Step 1

C Step 3

D Step 4

💡 Hint

Look at the 'Profile Active' column in the execution_table and variable_tracker.

If we remove application-dev.properties, what would app.name be at Step 4?

A MyApp-Dev

B MyApp

C undefined

D dev

💡 Hint

Without profile-specific properties, only application.properties is loaded, as shown in Step 1.

Concept Snapshot

Spring Boot loads application.properties first.
If a profile is active, it loads application-{profile}.properties next.
Profile properties override common ones.
Use spring.profiles.active to set the profile.
This allows different configs for dev, test, prod environments.

Full Transcript

When Spring Boot starts, it first checks if any profile is active using spring.profiles.active. It loads the common application.properties file. If a profile like 'dev' is active, it also loads application-dev.properties. The profile-specific properties override the common ones. For example, app.name is 'MyApp' by default but becomes 'MyApp-Dev' when the dev profile is active. Beans initialize with the combined configuration. If no profile is active, only the common properties apply. This mechanism helps run the app with different settings for different environments easily.

Practice

1. What is the main purpose of using profiles in Spring Boot configuration?

easy

A. To switch application settings easily for different environments

B. To write Java code faster

C. To create user interfaces

D. To manage database connections manually

Solution

1. Step 1: Understand what profiles do

   Profiles allow you to have different settings for different environments like development, testing, and production.

2. Step 2: Identify the main use

   Switching settings easily means you can run the same app with different configurations without changing code.

3. Final Answer:

   To switch application settings easily for different environments -> Option A

4. Quick Check:

   Profiles = environment-specific settings [OK]

Hint: Profiles = different settings for different environments [OK]

Common Mistakes:

• Thinking profiles are for writing code
• Confusing profiles with UI design
• Believing profiles manage database manually

2. Which of the following is the correct way to name a Spring Boot properties file for a profile named dev?

easy

A. application-dev.properties

B. application.properties-dev

C. dev-application.properties

D. application_dev.properties

Solution

1. Step 1: Recall Spring Boot profile file naming

   Spring Boot expects profile-specific files named as application-{profile}.properties.

2. Step 2: Match the correct pattern

   For profile 'dev', the file should be application-dev.properties.

3. Final Answer:

   application-dev.properties -> Option A

4. Quick Check:

   Profile file = application-{profile}.properties [OK]

Hint: Profile files use dash between application and profile [OK]

Common Mistakes:

• Using underscore instead of dash
• Placing profile after .properties
• Starting filename with profile name

3. Given these files:
application.properties contains server.port=8080
application-prod.properties contains server.port=9090
And the active profile is set to prod, what port will the Spring Boot app run on?

medium

A. 8080

B. 9090

C. Both 8080 and 9090

D. No port will be set

Solution

1. Step 1: Understand profile override behavior

   Properties in profile-specific files override those in the default application.properties when the profile is active.

2. Step 2: Apply active profile 'prod'

   Since 'prod' is active, server.port=9090 from application-prod.properties overrides 8080.

3. Final Answer:

   9090 -> Option B

4. Quick Check:

   Active profile properties override default [OK]

Hint: Active profile settings override defaults [OK]

Common Mistakes:

• Assuming default always applies
• Thinking both ports run simultaneously
• Ignoring profile activation

4. You wrote spring.profiles.active=dev in application.properties, but your app still uses default settings. What is the likely problem?

medium

A. The dev profile is not supported by Spring Boot

B. You need to restart the app after changing profiles

C. The profile-specific file is named application_dev.properties instead of application-dev.properties

D. Profiles cannot be set in application.properties

Solution

1. Step 1: Check profile file naming

   Spring Boot requires profile files named with dash, not underscore.

2. Step 2: Identify mismatch

   If the file is named application_dev.properties, Spring Boot won't recognize it for profile 'dev'.

3. Final Answer:

   Incorrect profile file naming with underscore -> Option C

4. Quick Check:

   Profile file must use dash, not underscore [OK]

Hint: Use dash, not underscore, in profile filenames [OK]

Common Mistakes:

• Thinking profiles can't be set in application.properties
• Forgetting to restart app (usually needed but not main issue here)
• Believing 'dev' profile is unsupported

5. You want to activate the test profile without changing application.properties. Which of these is a valid way to do it when running your Spring Boot app from the command line?

hard

A. java -jar app.jar -profile test

B. java -jar app.jar -Dspring.profiles.active=test

C. java -jar app.jar --profile=test

D. java -jar app.jar --spring.profiles.active=test

Solution

1. Step 1: Recall command line profile activation syntax

   Spring Boot uses --spring.profiles.active=profile to activate profiles via command line arguments.

2. Step 2: Check each option

   java -jar app.jar --spring.profiles.active=test uses the correct Spring Boot command-line syntax. java -jar app.jar -Dspring.profiles.active=test incorrectly places the -D JVM argument after -jar; correct would be java -Dspring.profiles.active=test -jar app.jar. Flags like -profile test and --profile=test are not supported by Spring Boot.

3. Final Answer:

   java -jar app.jar --spring.profiles.active=test -> Option D

4. Quick Check:

   Use --spring.profiles.active=profile on command line [OK]

Hint: Use --spring.profiles.active=profile to activate profiles [OK]

Common Mistakes:

• Using -profile or --profile flags incorrectly
• Confusing JVM -D options without proper placement
• Trying to set profile inside application.properties only