Skip to content

AnnotationConfigApplicationContext parent-child relationship

AnnotationConfigApplicationContext parent-child relationship allows a hierarchy of Spring contexts to be established where a child context can access beans from its parent, but the parent cannot access beans from the child^[600-developer__java__spring__multipleApplicationContext.md].

Overview

In the Spring Framework, the AnnotationConfigApplicationContext allows for hierarchical organization through the setParent(ApplicationContext parent) method^[600-developer__java__spring__multipleApplicationContext.md]. This creates a tree-like structure where a "root" context acts as the parent for one or more child contexts. This design facilitates the separation of concerns, allowing specific beans to be isolated in child contexts while shared services and infrastructure beans can reside in the root context^[600-developer__java__spring__multipleApplicationContext.md].

Environment Merging

When a parent context is set, the setParent method ensures that the child context inherits the environment configuration of the parent^[600-developer__java__spring__multipleApplicationContext.md].

If the parent is non-null and its environment is an instance of ConfigurableEnvironment, the child's environment will merge with the parent's^[600-developer__java__spring__multipleApplicationContext.md]. This ensures that configuration properties and profiles defined in the parent are available to the child.

Bean Visibility and Access

The primary characteristic of the parent-child relationship is the unidirectional visibility of beans^[600-developer__java__spring__multipleApplicationContext.md].

  • Child sees Parent: A child context can access beans defined in its parent context (and recursively up the hierarchy to the root).^[600-developer__java__spring__multipleApplicationContext.md]
  • Parent does not see Child: A parent context cannot access beans defined in its child contexts.

This isolation allows different modules or layers of an application (e.g., web layer vs. service layer) to have their own specific bean definitions while sharing common beans from a parent.

Lifecycle Management

The lifecycle of parent and child contexts is interdependent. The child context depends on the parent context being active to function correctly regarding shared beans, but the contexts can be closed independently^[600-developer__java__spring__multipleApplicationContext.md].

  • Startup: Typically, the parent context is started (refreshed) before the child context^[600-developer__java__spring__multipleApplicationContext.md]. However, in code examples, a parent can be created and have a child attached to it before the parent is explicitly refreshed, provided the hierarchy is respected before refresh() is called on the child^[600-developer__java__spring__multipleApplicationContext.md].
  • Shutdown: Closing a child context (e.g., via childCtx.close()) destroys beans specific to that child but does not necessarily close the parent context^[600-developer__java__spring__multipleApplicationContext.md]. The parent context may remain active and can serve other children. Conversely, if a parent context is closed, its children may lose access to the shared beans and effectively become non-functional if they rely on the parent, though they might technically still exist as objects until explicitly closed^[600-developer__java__spring__multipleApplicationContext.md].

The state of the context (active or closed) can be checked using the isActive() method^[600-developer__java__spring__multipleApplicationContext.md].

  • [[ApplicationContext]]
  • [[Dependency Injection]]
  • [[Spring Bean]]

Sources

  • 600-developer__java__spring__multipleApplicationContext.md