skip to content

Explain the difference between the ConfigData import mechanism and the legacy bootstrap context for Config Client, and how you'd re-enable bootstrap.

level: seniorimportance: should knowfreq 52%

answer

  1. bootstrap.yml = parent context, pre-2.4
  2. ConfigData = spring.config.import, single context, 2.4+
  3. ConfigServerConfigDataLocationResolver + ...Loader via spring.factories
  4. re-enable: spring-cloud-starter-bootstrap OR spring.cloud.bootstrap.enabled=true
  5. migrate config from bootstrap.yml to application.yml

basics

~20 s

Old versions created a separate 'bootstrap' application context from bootstrap.yml to fetch config before the main app. Since Spring Boot 2.4 that's replaced by spring.config.import handled inside the normal startup. To use the old way you add spring-cloud-starter-bootstrap or set spring.cloud.bootstrap.enabled=true.

solid answer

~40 s

Before Spring Boot 2.4, Config Client used a bootstrap context: a small parent ApplicationContext built from bootstrap.yml/properties that ran before the main context, fetched remote config, and handed it down. Since 2.4 / Spring Cloud 2020.0 the default is the ConfigData API — you declare spring.config.import=configserver: in ordinary application.yml, and a ConfigServerConfigDataLocationResolver plus ConfigServerConfigDataLoader (registered via spring.factories) load the config during Boot's standard Environment-preparation phase. No parent context, simpler ordering, and config coordinates live in application.yml instead of bootstrap.yml. If you must keep legacy behavior — e.g., during migration or for libraries that rely on the bootstrap phase — you re-enable it by adding spring-cloud-starter-bootstrap to the classpath or setting spring.cloud.bootstrap.enabled=true, which restores bootstrap.yml processing.

code

yaml · 21 lines
yaml
# --- Legacy bootstrap (pre-2.4) ---
# bootstrap.yml
spring:
  application:
    name: orders
  cloud:
    config:
      uri: http://config:8888
# needs spring-cloud-starter-bootstrap on classpath

# --- Modern ConfigData (2.4+) ---
# application.yml
spring:
  application:
    name: orders
  config:
    import: "configserver:http://config:8888"

# --- Re-enable legacy explicitly ---
# as a system/env property (governs bootstrap-context creation):
#   -Dspring.cloud.bootstrap.enabled=true

go deeper

for a junior

Know bootstrap.yml is the old way and spring.config.import is the new way.

for a middle

Explain the parent-context vs single-context difference and where config now lives.

for a senior

Name the resolver/loader classes, the spring.factories registration, and how to toggle bootstrap back on.

for a principal

Lead a fleet migration off bootstrap, audit precedence/failure-mode changes, and manage libraries that still depend on the bootstrap phase.

## Two eras of the Config Client ### Legacy: the bootstrap context (pre-2.4) Spring Cloud originally solved 'fetch config before the app starts' by creating a **separate bootstrap ApplicationContext**: - Config lived in **`bootstrap.yml`** / `bootstrap.properties`, read by a `PropertySourceBootstrapConfiguration`. - This bootstrap context is a **parent** of the main context; it runs first, contacts the Config Server, and pushes the fetched property sources into the child (main) Environment. - It required `spring-cloud-context` / the bootstrap infrastructure to be active. Downsides: a whole second context with its own lifecycle, confusing property-source ordering, and behavior that diverged from Boot's own externalized-config model. ### Modern: the ConfigData API (Boot 2.4+, Cloud 2020.0+) Spring Boot 2.4 introduced the **ConfigData API** — a pluggable way to import config locations during normal startup via `spring.config.import`. Spring Cloud Config plugs into it: - **`ConfigServerConfigDataLocationResolver`** recognizes the `configserver:` (and `optional:configserver:`) location prefix and resolves it to a `ConfigServerConfigDataResource`. - **`ConfigServerConfigDataLoader`** does the actual HTTP call to the server and returns the property sources. - Both are registered through `META-INF/spring.factories` (`org.springframework.boot.context.config.ConfigDataLocationResolver` and `...ConfigDataLoader`). - All of this happens **inside the single main context's Environment-preparation phase** — no parent bootstrap context. Benefits: connection details live in ordinary `application.yml`, ordering follows Boot's documented ConfigData rules, `optional:` and profile-specific imports work naturally, and there's one lifecycle to reason about. ## Re-enabling the legacy bootstrap Some older libraries/integrations still assume the bootstrap phase (e.g., certain Vault or encryption setups historically). To turn it back on: 1. **Add the dependency:** `org.springframework.cloud:spring-cloud-starter-bootstrap`, **or** 2. **Set a property:** `spring.cloud.bootstrap.enabled=true` (as a system property / env var, since it governs whether the bootstrap context is created). Either restores `bootstrap.yml` processing and the parent-context behavior. ## Migration gotchas - Move `spring.cloud.config.*` and `spring.application.name` from `bootstrap.yml` into `application.yml`, and add `spring.config.import=configserver:`. - Property-source **ordering can shift** subtly between the two models — re-verify precedence (see the override flags) after migrating. - Don't accidentally have **both** active; if `spring-cloud-starter-bootstrap` is on the classpath the bootstrap phase runs even though you intended the ConfigData path. - `optional:` and `fail-fast` semantics apply to the ConfigData path; the bootstrap path has its own historical handling of failure — behavior may differ, so test the down-server case explicitly. ## When to use which - **Default to ConfigData** for anything new — it's the supported, simpler model. - **Use bootstrap only** to satisfy a legacy dependency that still requires it, and plan to migrate off.

  • Which classes let the configserver: prefix work in the ConfigData model, and how are they registered?
    ConfigServerConfigDataLocationResolver (resolves the configserver: location) and ConfigServerConfigDataLoader (performs the HTTP fetch), registered via META-INF/spring.factories as a ConfigDataLocationResolver and ConfigDataLoader.
  • A team reports their bootstrap.yml is being ignored after upgrading to Spring Boot 2.4. Why?
    The bootstrap context is disabled by default since 2.4. They must either migrate settings to application.yml with spring.config.import, or re-enable bootstrap via spring-cloud-starter-bootstrap / spring.cloud.bootstrap.enabled=true.

saying these in an interview costs you the question

  • Saying bootstrap.yml still works out of the box in current Spring Boot
  • Believing the ConfigData mechanism creates a separate parent context (it does not)
  • Not knowing how to re-enable the legacy bootstrap phase

context

resolving links…