Introduction

Spring Boot is designed to read external configuration with very little setup. In most applications, the simplest answer is to place values in application.properties or application.yml and bind them with @Value, @ConfigurationProperties, or the Environment API depending on how structured the configuration is.

Read a Single Property with @Value

For one or two simple settings, @Value is fine:

app.name=Inventory Service
app.page-size=50

1import org.springframework.beans.factory.annotation.Value;
2import org.springframework.stereotype.Component;
3
4@Component
5public class AppInfo {
6
7    @Value("${app.name}")
8    private String appName;
9
10    @Value("${app.page-size}")
11    private int pageSize;
12
13    public String getAppName() {
14        return appName;
15    }
16
17    public int getPageSize() {
18        return pageSize;
19    }
20}

This is easy to understand, but it becomes noisy once you have many related properties.

Prefer @ConfigurationProperties for Groups of Settings

When several settings belong together, a typed configuration class is cleaner:

app.client.base-url=https://api.example.com
app.client.connect-timeout=5
app.client.read-timeout=30

1import org.springframework.boot.context.properties.ConfigurationProperties;
2
3@ConfigurationProperties(prefix = "app.client")
4public class ClientProperties {
5
6    private String baseUrl;
7    private int connectTimeout;
8    private int readTimeout;
9
10    public String getBaseUrl() {
11        return baseUrl;
12    }
13
14    public void setBaseUrl(String baseUrl) {
15        this.baseUrl = baseUrl;
16    }
17
18    public int getConnectTimeout() {
19        return connectTimeout;
20    }
21
22    public void setConnectTimeout(int connectTimeout) {
23        this.connectTimeout = connectTimeout;
24    }
25
26    public int getReadTimeout() {
27        return readTimeout;
28    }
29
30    public void setReadTimeout(int readTimeout) {
31        this.readTimeout = readTimeout;
32    }
33}

Then enable it:

1import org.springframework.boot.context.properties.EnableConfigurationProperties;
2import org.springframework.context.annotation.Configuration;
3
4@Configuration
5@EnableConfigurationProperties(ClientProperties.class)
6public class ClientConfig {
7}

Now other beans can depend on ClientProperties as one coherent object.

Use Environment for Dynamic Lookups

Sometimes you need to read properties dynamically rather than bind them up front:

1import org.springframework.core.env.Environment;
2import org.springframework.stereotype.Service;
3
4@Service
5public class FeatureService {
6
7    private final Environment environment;
8
9    public FeatureService(Environment environment) {
10        this.environment = environment;
11    }
12
13    public boolean isFeatureEnabled() {
14        return Boolean.parseBoolean(
15            environment.getProperty("feature.reporting.enabled", "false")
16        );
17    }
18}

This is useful when the property name is conditional or when inline defaults are convenient.

Spring Boot Already Reads application.properties

One important point is that you usually do not need to load application.properties manually. Spring Boot automatically reads standard configuration files from the classpath and external config locations.

That means adding @PropertySource for the default application file is usually unnecessary.

Use a Custom Properties File Only When Needed

If you truly need an extra custom file, @PropertySource can load it:

mail.sender=[email protected]
mail.region=ca-central-1

1import org.springframework.context.annotation.Configuration;
2import org.springframework.context.annotation.PropertySource;
3
4@Configuration
5@PropertySource("classpath:mail.properties")
6public class MailPropertyConfig {
7}

After that, the properties are available through @Value or Environment just like other property sources.

In many projects, however, a separate custom file is not needed. Keeping most configuration in application.properties and profile-specific files is simpler.

Profile-Specific Configuration

Spring Boot also supports profile-specific files such as:

• 'application-dev.properties'
• 'application-prod.properties'

This is often a better answer than making many custom property files because it matches Spring Boot's native configuration model.

Common Pitfalls

• Using @Value everywhere even when a typed configuration class would be clearer.
• Adding @PropertySource for application.properties even though Spring Boot already loads it.
• Putting custom property files in the wrong location so they never reach the classpath.
• Scattering configuration lookups throughout the codebase instead of grouping related settings.
• Ignoring missing-property behavior until it fails at runtime in a less obvious place.

Summary

• Put standard configuration in application.properties or application.yml.
• Use @Value for a small number of simple properties.
• Use @ConfigurationProperties when several related settings belong together.
• Use Environment for dynamic lookups and inline defaults.
• Reach for @PropertySource only when you truly need an additional custom properties file.