Reinitialize Singleton Bean in Spring Context

1. Overview

In this tutorial, we’ll look at the ways to reinitialize singleton Spring beans at runtime.

By default, Spring beans with the singleton scope aren’t reinitialized in the application lifecycle. However, sometimes it may be required to recreate the bean — when a property is updated, for example. We’ll look at a few methods to do this.

2. Code Setup

To understand this, we’ll create a small project. We’ll create a bean that reads configuration properties from a configuration file and keeps them in memory for faster access. If the properties in the file change, it may be necessary to reload the configuration.

2.1. Singleton Bean

Let’s start by creating the ConfigManager class:

@Service("ConfigManager")
public class ConfigManager {

    private static final Log LOG = LogFactory.getLog(ConfigManager.class);

    private Map<String, Object> config;

    private final String filePath;

    public ConfigManager(@Value("${config.file.path}") String filePath) {
        this.filePath = filePath;
        initConfigs();
    }

    private void initConfigs() {
        Properties properties = new Properties();
        try {
            properties.load(Files.newInputStream(Paths.get(filePath)));
        } catch (IOException e) {
            LOG.error("Error loading configuration:", e);
        }
        config = new HashMap<>();
        for (Map.Entry<Object, Object> entry : properties.entrySet()) {
            config.put(String.valueOf(entry.getKey()), entry.getValue());
        }
    }

    public Object getConfig(String key) {
        return config.get(key);
    }
}

Here are a few points to note about this class:

• Calling the method initConfigs() from the constructor loads the file as soon as the bean is constructed.
• The initConfigs() method converts the contents of the file into a Map named config.
• The getConfig() method is used to read a property by its key.

Another point to note is the constructor dependency injection. We’ll later make use of it when we need to replace the bean.

The config file is at the path src/main/resources/config.properties and contains a single property:

property1=value1

2.2. Controller

To test the ConfigManager, let’s create a controller:

@RestController
@RequestMapping("/config")
public class ConfigController {

    @Autowired
    private ConfigManager configManager;

    @GetMapping("/{key}")
    public Object get(@PathVariable String key) {
        return configManager.getConfig(key);
    }
}

We can run the application and read the configuration by hitting the URL http://localhost:8080/config/property1

Next, we want to change the value of the property in the file and have it reflected when we read the configuration by hitting the same URL again. Let’s look at a few ways to do that.

3. Reloading Properties With a Public Method

If we want to reload the properties and not recreate the object itself, we can simply create a public method that initializes the map again. In our ConfigManager, let’s add a method that calls the method initConfigs():

public void reinitializeConfig() {
    initConfigs();
}

We can then call this method when we want to reload the properties. Let’s expose another method in the controller class that calls the reinitializeConfig() method:

@GetMapping("/reinitializeConfig")
public void reinitializeConfig() {
    configManager.reinitializeConfig();
}

We can now run the application and test it by following a few simple steps:

• Hitting the URL http://localhost:8080/config/property1 returns value1.
• We’ll then change the value of property1 from value1 to value2.
• We can then hit the URL http://localhost:8080/config/reinitializeConfig to reinitialize the config map.
• If we hit the URL http://localhost:8080/config/property1 again, we’ll find that the value returned is value2.

4. Reinitializing the Singleton Bean

Another way to reinitialize the bean is by recreating it in the context. The recreation can be done either by using custom code and calling constructors or by deleting the bean and having the context reinitialize it automatically. Let’s look at both ways.

4.1. Replacing the Bean in the Context

We can delete the bean from the context and replace it with a new instance of the ConfigManager. Let’s define another method in our controller to do so:

@GetMapping("/reinitializeBean")
public void reinitializeBean() {
    DefaultSingletonBeanRegistry registry = (DefaultSingletonBeanRegistry) applicationContext.getAutowireCapableBeanFactory();
    registry.destroySingleton("ConfigManager");
    registry.registerSingleton("ConfigManager", new ConfigManager(filePath)); 
}

First, we get the instance of DefaultSingletonBeanRegistry from the application context. Next, we call the destroySingleton() method to destroy the instance of the bean named ConfigManager. Finally, we create a new instance of ConfigManager and register it with the factory by calling the registerSingleton() method.

To create a new instance, we’ve used the constructor we defined in the ConfigManager. Any dependencies that the bean depends on must be passed through the constructor.

The registerSingleton() method not only creates the bean in the context but also autowires it to the dependent objects.

Invoking the /reinitializeBean endpoint updates the ConfigManager bean in the controller. We can test the re-initializing behavior using the same steps as in the previous method.

4.2. Destroying the Bean in the Context

In the earlier method, we needed to pass dependencies through the constructor. Sometimes, we may not need to create a new instance of the bean or may not have access to the dependencies required. In this case, another possibility is just to destroy the bean in the context.

The context takes care of creating the bean again when the bean is requested again. In that case, it will be created using the same steps as the initial bean creation.

To demonstrate this, let’s create a new controller method that destroys the bean but doesn’t create it again:

@GetMapping("/destroyBean")
public void destroyBean() {
    DefaultSingletonBeanRegistry registry = (DefaultSingletonBeanRegistry) applicationContext.getAutowireCapableBeanFactory();
    registry.destroySingleton("ConfigManager");
}

This won’t alter the reference to the bean already held by the controller. To access the latest state, we’ll need to read it directly from the context.

Let’s create a new controller to read the configuration. This controller will depend on the latest ConfigManager bean in the context:

@GetMapping("/context/{key}")
public Object getFromContext(@PathVariable String key) {
    ConfigManager dynamicConfigManager = applicationContext.getBean(ConfigManager.class);
    return dynamicConfigManager.getConfig(key);
}

We can test the above method using a few simple steps:

• Hitting the URL http://localhost:8080/config/context/property1 returns value1.
• We can then hit the URL http://localhost:8080/config/destroyBean to destroy the ConfigManager.
• We’ll then change the value of property1 from value1 to value2.
• If we hit the URL http://localhost:8080/config/context/property1 again, we’ll find that the value returned is value2.

5. Conclusion

In this article, we explored ways to reinitialize a singleton bean. We looked at a way to alter the properties of the bean without recreating it. We also looked at ways to force the recreation of the bean in the context.