A Guide to Fallback Beans in Spring Framework

1. Overview

In this tutorial, we’ll discuss the concept of fallback beans in the Spring Framework. Fallback beans were introduced in Spring Framework version 6.2.0-M1. They provide an alternative implementation when another bean of the same type is unavailable or fails to initialize.

This can be useful in scenarios where we want to gracefully handle failures and provide a fallback mechanism to ensure the application continues to function.

2. Primary and Fallback Beans

In a Spring application, we can define multiple beans of the same type. By default, Spring uses the bean name and type to identify beans. When we have multiple beans of the same name and type, we can mark one of them as the primary bean using the @Primary annotation to take precedence over others. This is useful if multiple beans of the same type are created when the application context is initialized, and we want to specify which bean should be used by default.

Similarly, we can define a fallback bean to provide an alternative implementation when no other qualifying bean is available. We can use the annotation @Fallback to mark a bean as a fallback bean. Only when no other bean of the same name is available, the fallback bean will be injected into the application context.

3. Code Example

Let’s look at an example to demonstrate the usage of primary and fallback beans in a Spring application. We’ll create a small application that sends a message using different messaging services. Let’s assume we have multiple messaging services in production and non-production environments and need to switch between them to optimize performance and cost.

3.1. Messaging Interface

First, let’s define an interface for our services:

public interface MessagingService {
    void sendMessage(String text);
}

The interface has one method to send the provided text as a message.

3.2. Primary Bean

Next, let’s define an implementation of the messaging service as the primary bean:

@Service
@Profile("production")
@Primary
public class ProductionMessagingService implements MessagingService {
    @Override
    public void sendMessage(String text) {
       // implementation in production environment
    }
}

In this implementation, we use the @Profile annotation to specify that this bean is available only when the production profile is active. We also mark it as the primary bean using the @Primary annotation.

3.3. Non-primary Bean

Let’s define another implementation of the messaging service as a non-primary bean:

@Service
@Profile("!test")
public class DevelopmentMessagingService implements MessagingService {
    @Override
    public void sendMessage(String text) {
        // implementation in development environment
    }
}

In this implementation, we use the @Profile annotation to specify that this bean is available when the test profile isn’t active. This means it will be available in all profiles except the test profile.

3.4. Fallback Bean

Finally, let’s define a fallback bean for the messaging service:

@Service
@Fallback
public class FallbackMessagingService implements MessagingService {
    @Override
    public void sendMessage(String text) {
        // fallback implementation
    }
}

In this implementation, we use the @Fallback annotation to mark this bean as a fallback bean. This bean will be injected only when no other bean of the same type is available.

4. Testing

Now, let’s test our application by autowiring the messaging service and checking which implementation is used based on the active profile.

4.1. No Profile

In the first test, we don’t activate any profile. Since the production profile isn’t activated, ProductionMessagingService isn’t available, and the other two beans are available. 

When we test the messaging service, it should use DevelopmentMessagingService as it takes precedence over the fallback bean:

@RunWith(SpringRunner.class)
@SpringBootTest(classes = {FallbackMessagingService.class, DevelopmentMessagingService.class, ProductionMessagingService.class})
public class DevelopmentMessagingServiceUnitTest {
    @Autowired
    private MessagingService messagingService;

    @Test
    public void givenNoProfile_whenSendMessage_thenDevelopmentMessagingService() {
        assertEquals(messagingService.getClass(), DevelopmentMessagingService.class);
    }
}

4.2. Production Profile

Next, let’s activate the production profile. Now the ProductionMessagingService should be available, and the other two beans are also available.

When we test the messaging service, it should use ProductionMessagingService as it’s marked as the primary bean:

@RunWith(SpringRunner.class)
@SpringBootTest(classes = {FallbackMessagingService.class, DevelopmentMessagingService.class, ProductionMessagingService.class})
@ActiveProfiles("production")
public class ProductionMessagingServiceUnitTest {
    @Autowired
    private MessagingService messagingService;

    @Test
    public void givenProductionProfile_whenSendMessage_thenProductionMessagingService() {
        assertEquals(messagingService.getClass(), ProductionMessagingService.class);
    }
}

4.3. Test Profile

Finally, let’s activate the test profile. This removes the DevelopmentMessagingService bean from the context. Since we’ve removed the production profile, ProductionMessagingService is also not available.

In this case, the messaging service should use the FallbackMessagingService as it’s the only available bean:

@RunWith(SpringRunner.class)
@SpringBootTest(classes = {FallbackMessagingService.class, DevelopmentMessagingService.class, ProductionMessagingService.class})
@ActiveProfiles("test")
public class FallbackMessagingServiceUnitTest {
    @Autowired
    private MessagingService messagingService;

    @Test
    public void givenTestProfile_whenSendMessage_thenFallbackMessagingService() {
        assertEquals(messagingService.getClass(), FallbackMessagingService.class);
    }
}

5. Conclusion

In this tutorial, we discussed the concept of fallback beans in the Spring Framework. We saw how to define primary and fallback beans and how to use them in a Spring application. Fallback beans provide an alternative implementation when any other qualifying bean isn’t available. This can be useful when switching between different implementations based on the active profile or other conditions.