I just announced the new Spring 5 modules in REST With Spring:


1. Overview

It’s possible to create separate contexts and organize them in a hierarchy in Spring Boot.

A context hierarchy can be defined in different ways in Spring Boot application. In this article, we’ll look at how we can create multiple contexts using the fluent builder API.

As we won’t go into details on how to set up a Spring Boot application, you might want to check out this article.

2. Application Context Hierarchy

We can have multiple application contexts which share a parent-child relationship.

A context hierarchy allows multiple child contexts to share beans which reside in the parent context. Each child context can override configuration inherited from the parent context.

Furthermore, we can use contexts to prevent beans registered in one context from being accessible in another. This facilitates the creation of loosely coupled modules.

Here some points worth noting are that a context can have only one parent while a parent context can have multiple child contexts. Also, a child context can access beans in the parent context but not vice-versa.

3. Using SpringApplicationBuilder API

The SpringApplicationBuilder class provides a fluent API to create a parent-child relationship between contexts using parent()child() and sibling() methods.

To exemplify the context hierarchy, we’ll set up a non-web parent application context with 2 child web contexts.

To demonstrate this, we’ll start two instances of embedded Tomcat each with its own web application context and both running in a single JVM.

3.1. Parent Context

To begin, let’s create a service bean along with a bean definition class which reside in the parent package. We want this bean to return a greeting which is displayed to the client of our web application:

public class HomeService implements IHomeService {

    public String getGreeting() {
        return "Welcome User";

And the bean definition class:

public class ServiceConfig {}

Next, we’ll create the configuration for the two child contexts.

3.2. Child Context

Since all contexts are configured using the default configuration file, we need to provide separate configurations for properties which cannot be shared among contexts such as server ports.

To prevent conflicting configurations being picked up by the auto-configuration, we’ll also keep the classes in separate packages.

Let’s start by defining a properties file for the first child context:



Note that we’ve configured the port and context path, as well as a JMX name so the application names don’t conflict.

Let’s now add the main configuration class for this context:

public class Ctx1Config {
    public IHomeService homeService() {
        return new GreetingService();

This class provides a new definition for the homeService bean that will overwrite the one from the parent.

Let’s see the definition of the GreetingService class:

public class GreetingService implements IHomeService {

    public String getGreeting() {
        return "Greetings for the day";

Finally, we’ll add a controller for this web context that use the homeService bean to display a message to the user:

public class Ctx1Controller {

    HomeService homeService;

    public String greeting() {

        return homeService.getGreeting();

3.3. Sibling Context

For our second context, we’ll create a controller and configuration class which are very similar to the ones in the previous section.

This time, we won’t create a homeService bean – as we’ll access it from the parent context.

First, let’s add a properties file for this context:



And the configuration class for the sibling application:

public class Ctx2Config {}

Let’s also add a controller, which has HomeService as a dependency:

public class Ctx2Controller {

    IHomeService homeService;

    @GetMapping(value = "/greeting", produces = "application/json")
    public String getGreeting() {
        return homeService.getGreeting();

In this case, our controller should get the homeService bean from the parent context.

3.4. Context Hierarchy

Now we can put everything together and define the context hierarchy using SpringApplicationBuilder:

public class App {
    public static void main(String[] args) {
        new SpringApplicationBuilder()

Finally, on running the Spring Boot App we can access both applications at their respective ports using localhost:8081/ctx1/home and localhost:8082/ctx2/greeting.

4. Conclusion

Using the SpringApplicationBuilder API, we first created a parent-child relationship between two contexts of an application. Next, we covered how to override the parent configuration in the child context. Lastly, we added a sibling context to demonstrate how the configuration in the parent context can be shared with other child contexts.

The source code of the example is available over on GitHub.

I just announced the new Spring 5 modules in REST With Spring:


Leave a Reply

1 Comment threads
1 Thread replies
Most reacted comment
Hottest comment thread
2 Comment authors
Grzegorz PiwowarekArgrmn Recent comment authors
newest oldest most voted
Notify of

Is this necessary in a microservice world? Don’t spring profiles provide a more elegant and easier way to accomplish the second goal? Perhaps this setup is to workaround some configurations are hard to customize or override? Please explain..

Grzegorz Piwowarek

No, it isn’t but it’s always good to be aware of one more tool in your toolbox 🙂