Dynamic ApplicationContext hierarchy construction¶
Dynamic ApplicationContext hierarchy construction involves creating and linking multiple Spring ApplicationContext instances programmatically at runtime, rather than relying on a single statically defined context^[600-developer__java__spring__multipleApplicationContext.md]. This architecture allows for the creation of a hierarchical structure where child contexts can inherit beans and configuration from their parents^[600-developer__java__spring__multipleApplicationContext.md].
Hierarchy Structure¶
The construction involves creating a root context and subsequent child contexts.^[600-developer__java__spring__multipleApplicationContext.md]
* Root Context: Acts as the parent (e.g., parentCtx).
* Child Context: Linked to the root (e.g., childCtx).
* Nested Child Context: A child context can also act as a parent to another context (e.g., childCtx2 having childCtx as its parent)^[600-developer__java__spring__multipleApplicationContext.md].
This creates a tree-like structure where a central root context manages shared resources, while child contexts can define specific beans.
Implementation¶
The process typically involves three main steps:
1. Instantiation: Create instances of AnnotationConfigApplicationContext^[600-developer__java__spring__multipleApplicationContext.md].
2. Registration: Register specific configuration classes or beans for each context^[600-developer__java__spring__multipleApplicationContext.md].
3. Linking: Use the setParent(ApplicationContext parent) method to establish the hierarchy^[600-developer__java__spring__multipleApplicationContext.md].
Environment Merging¶
When a parent context is set via setParent, the Spring framework automatically handles environment configuration.^[600-developer__java__spring__multipleApplicationContext.md#L9-L18]
If the parent context possesses a ConfigurableEnvironment, the child context merges this environment into its own^[600-developer__java__spring__multipleApplicationContext.md#L9-L18].
Lifecycle Management¶
To activate the contexts, the refresh() method must be called.^[600-developer__java__spring__multipleApplicationContext.md]
It is common practice to refresh the root context first, followed by its children^[600-developer__java__spring__multipleApplicationContext.md].
Bean Visibility¶
A key characteristic of the hierarchy is the direction of bean visibility.^[600-developer__java__spring__multipleApplicationContext.md] * Downward Visibility: A child context can access and retrieve beans defined in its parent (or root) context^[600-developer__java__spring__multipleApplicationContext.md]. * Upward Isolation: The parent context cannot see or access beans defined in its child contexts^[600-developer__java__spring__multipleApplicationContext.md].
For example, in a hierarchy root -> child -> grandchild, the grandchild can retrieve beans from both child and root, but root cannot retrieve beans from child or grandchild^[600-developer__java__spring__multipleApplicationContext.md].
Dynamic Addition¶
The hierarchy can be constructed dynamically even after the root context has already been started.^[600-developer__java__spring__multipleApplicationContext.md]
This allows for an "appendable" architecture where new modules or contexts can be attached to a running application, provided the parent reference and refresh() are correctly handled during the attachment^[600-developer__java__spring__multipleApplicationContext.md].
Related Concepts¶
- Spring Framework
- [[Dependency Injection]]