spring-cloud
RefreshScode refresh mechanism is not safe
Is your feature request related to a problem? Please describe.
@RefreshScope may not be secure enough as it will first destroy the current bean and then create a new bean. What if the environment properties encounter an exception when creating a new bean? This online running application will be a disaster.
Describe the solution you'd like
Is it possible to adjust the order and first try creating a temporary bean? If it can be initialized normally, then replace the original bean. This will be a significant optimization for runtime configuration updates.
Describe alternatives you've considered A clear and concise description of any alternative solutions or features you've considered.
Additional context
In addition，if it is possible to move @RefreshScope from spring-cloud to spring boot? it should not be bundled to spring cloud project.
I am a core builder in the Nacos community (https://nacos.io/en/) which is widely used by chinese developer community and I am responsible for config center. We want to implement all configurations on the hosted application side, support elegant updates during runtime, and improve the efficiency of business software iteration. If Spring can support elegant refresh beans, then there is no need for every second party middleware to implement this feature
What if the environment properties encounter an exception when creating a new bean?
If the exception is caused by misconfiguration, fix the configuration and refresh.
Is it possible to adjust the order and first try creating a temporary bean? If it can be initialized normally, then replace the original bean.
What if some resource can only be held by one bean at any moment? For example, a lock is acquired on bean initialization and released on bean destruction, creating a temporary bean will indefinitely wait for lock release.
What if the environment properties encounter an exception when creating a new bean?
If the exception is caused by misconfiguration, fix the configuration and refresh.
Is it possible to adjust the order and first try creating a temporary bean? If it can be initialized normally, then replace the original bean.
What if some resource can only be held by one bean at any moment? For example, a lock is acquired on bean initialization and released on bean destruction, creating a temporary bean will indefinitely wait for lock release.
We are trying to explore a more secure and elegant refresh mechanism. The current situation you mentioned is the problem we need to solve. As for the lock conflict problem of bean creation and destruction, it is just a technical issue that we need to solve in actual implementation