Configuration & Profiles
Where values come from
Spring reads many sources and lets later ones win:
- command line —
--server.port=9000 - environment variables —
SERVER_PORT=9000 application-{profile}.propertiesapplication.properties- defaults in code
Relaxed binding maps server.port, SERVER_PORT and server-port to the same property.
Reading single values
The part after : is the default.
Typed configuration
Better for anything with more than one key:
Inject MailProperties like any other bean. Records give you immutability and constructor
binding for free.
Tip
Add spring-boot-configuration-processor as an optional dependency and your IDE
autocompletes your own properties.
Validating configuration
A bad value now fails at startup, not at the first send.
Profiles
A profile is a named set of configuration.
Beans can be profile-specific:
Secrets
Never commit passwords. Pass them as environment variables and reference them:
Warning
application.properties ends up inside the jar. Anything environment-specific or secret
belongs outside it.
Useful built-in properties
| Property | Effect |
|---|---|
server.port | HTTP port, 0 = random |
spring.application.name | name in logs, metrics, traces |
logging.level.<package> | log level per package |
logging.console.enabled | new in Boot 4: turn console logging off |
spring.threads.virtual.enabled | virtual threads for request handling |
spring.jpa.hibernate.ddl-auto | schema handling, none in production |
★ Exercises
- Move a hard-coded string into
application.propertiesand inject it with@Value. - Convert it to a
@ConfigurationPropertiesrecord with three keys. - Add
@Validatedand make startup fail on an empty value. - Create
application-dev.propertieswithlogging.level.com.example=DEBUGand run with that profile. - Override the port three ways: file, environment variable, command line. Which wins?