This post is simply demonstrating this feature — I have yet to find a good use of it in the projects I have worked on. Spring Cloud uses this feature for creating a bootstrap context where properties are loaded up, if required, from an external configuration server, which is made available to the main application context later on.

To quickly take a step back — a Spring Application Context manages the lifecycle of all the beans registered with it. Application Context hierarchies provide a way to reuse beans — beans defined in the parent context are accessible in the child contexts.

Consider a contrived use-case of using multiple application contexts and the application context hierarchy — this is to provide two different ports with a different set of endpoints at each of these ports.

Child1 and Child2 are typical Spring Boot Applications, along these lines:

Each of the applications resides in its own root package to avoid collisions when scanning for beans. Note that the bean in the child contexts depends on a bean that is expected to come from the root context.

The port to listen on is provided as properties, since the two contexts are expected to listen on different ports I have explicitly specified the property file to load with a content along these lines:

server.port=8080
spring.application.name=child1

Given this setup, Spring Boot provides a fluid interface to load up the root context and the two child contexts:

The application context returned by the SpringBootApplicationBuilder appears to be the final one in the chain, defined via ChildContext2 above.

If the application is now started up, there would be a root context with two different child contexts, each exposing an endpoint via a different port. A visualization via the /beans actuator endpoint shows this:

Not everything is clean, though. There are errors displayed in the console related to exporting JMX endpoints, however, these are informational and don't appear to affect the start-up.