skip to content

What is SpringApplicationBuilder and when would you use its parent/child context feature?

level: seniorimportance: should knowfreq 34%

answer

  1. fluent wrapper over SpringApplication
  2. parent -> child -> sibling hierarchy
  3. child sees parent beans, one-way
  4. shared infra in parent, isolated children
  5. build() vs run(); per-level web/profiles/props

basics

~10 s

SpringApplicationBuilder is a fluent API for configuring and launching a SpringApplication. Its distinctive feature is building a parent/child ApplicationContext hierarchy — a shared parent context whose beans are visible to isolated child contexts.

solid answer

~50 s

SpringApplicationBuilder is a builder-style wrapper over SpringApplication that lets you configure the app fluently — sources, profiles, web type, banner, default properties, listeners, initializers — before calling run(). Its standout capability is creating a **context hierarchy**: builder().sources(Parent.class).child(Child.class).run(args) builds a parent context and a child whose beans can see the parent's but not vice versa. You use it when you need shared infrastructure beans (datasource, security, common services) in a parent, with one or more children that have isolated, potentially conflicting bean definitions — e.g. running two web contexts, or a shared core plus a specialized module. Each level can have its own web type, profiles, and property sources via parent()/child()/sibling(). In practice hierarchies are uncommon in typical Boot apps; most teams use the builder just for its fluent configuration, or in tests. It's also what @SpringBootApplication-based tests and some embedding scenarios use under the hood.

code

java · 10 lines
java
public static void main(String[] args) {
    new SpringApplicationBuilder()
        .sources(SharedInfraConfig.class)     // parent: DataSource, security, etc.
        .web(WebApplicationType.NONE)          // parent is non-web
        .child(ModuleAConfig.class)            // child sees parent beans
        .web(WebApplicationType.SERVLET)        // child is a web app
        .properties("server.port=8081")
        .run(args);
    // Child can @Autowired beans from SharedInfraConfig; parent cannot see ModuleA beans.
}

go deeper

for a junior

May only know it's a fluent way to configure and start the app.

for a middle

Should know the main fluent methods (web, profiles, properties, banner).

for a senior

Should explain parent/child/sibling hierarchies, one-way visibility, and when to use them.

for a principal

Should weigh hierarchy complexity vs a single context and reason about event/shutdown propagation and modular isolation.

## What it is `SpringApplicationBuilder` is a fluent builder around `SpringApplication`. Instead of constructing a `SpringApplication`, calling several setters, then `run`, you chain calls: ```java new SpringApplicationBuilder(App.class) .web(WebApplicationType.SERVLET) .profiles("prod") .bannerMode(Banner.Mode.OFF) .properties("server.port=9090") .run(args); ``` Every method returns the builder, so configuration reads top-to-bottom and ends with `run(args)` (or `build()` to get the `SpringApplication` without running). ## The headline feature: context hierarchies The builder can assemble a **parent/child `ApplicationContext` hierarchy**: ```java new SpringApplicationBuilder() .sources(ParentConfig.class) // parent context .child(ChildConfig.class) // child context, parent set automatically .run(args); ``` - **Parent** holds shared beans (e.g. a common `DataSource`, security, messaging). - **Child** contexts can **see the parent's beans** (parent-first lookup) but the parent **cannot see** the child's — visibility is one-directional. Children are isolated from each other. - `parent(...)` sets/creates a parent for the current builder; `child(...)` creates a child of the current context; `sibling(...)` creates another child of the same parent. - Each level can independently set `web(...)`, `profiles(...)`, `properties(...)`, `initializers(...)`, `listeners(...)`. ## When to use hierarchies - Multiple web/application contexts that must share infrastructure but keep isolated, possibly conflicting, bean definitions (classic Spring MVC 'root + servlet' style modeled programmatically). - Running several 'sub-applications' in one JVM with a common core. - Legacy/modular embedding where isolation matters. They are **not** the default for ordinary Boot apps — a single flat context is simpler and preferred. Reach for a hierarchy only when isolation + sharing is a real requirement. ## Non-hierarchy uses (the common case) Most usage is just the fluent configuration: setting the banner mode, default properties, additional sources, or web type in a readable chain — especially handy when embedding Boot in another app or in test setup. `build()` (without `run`) is useful to obtain a configured `SpringApplication` you hand elsewhere. ## Configuration methods worth knowing - `.sources(...)` — add primary sources. - `.web(WebApplicationType)` — force the web type. - `.profiles(...)` — activate profiles. - `.properties(...)` — supply default properties (String key=value, Map, or Properties). - `.bannerMode(Banner.Mode)` / `.banner(Banner)`. - `.initializers(ApplicationContextInitializer...)` / `.listeners(ApplicationListener...)`. - `.parent(...)` / `.child(...)` / `.sibling(...)` — hierarchy. - `.build()` — return the `SpringApplication`; `.run(args)` — start it and return the (leaf) `ConfigurableApplicationContext`. ## Gotchas - In a hierarchy, **bean visibility is parent-first and one-way**: a parent bean can't `@Autowired` a child bean. - Property sources and profiles set on one level don't automatically apply to another — set them per level. - Overusing hierarchies adds real complexity (event propagation, shutdown ordering); prefer a single context unless isolation is genuinely needed. - `run()` returns the **child/leaf** context; keep references if you need the parent.

  • In a parent/child hierarchy, can a parent bean autowire a child bean?
    No. Visibility is one-directional and parent-first: children see parent beans, but the parent cannot see or inject child beans.
  • Which context does builder.run(args) return in a hierarchy?
    The leaf (child) context. If you need the parent you must capture it separately, since run returns the most-derived context.

saying these in an interview costs you the question

  • Claiming parent and child share beans bidirectionally
  • Saying every Boot app should use a context hierarchy
  • Confusing SpringApplicationBuilder with the Lombok/builder pattern for beans

context

resolving links…