issue of spring dynamic configuration

[laywin]

Why you need it?

Is your feature request related to a problem? Please describe in details
目前在spring boot环境下，seata感知不到环境变量的改变，即使配置中心已经将配置推送到了应用程序的environment, 这里配置中心并不是为seata单独开启的配置中心，感觉这种情况很普遍. 我看了一下因为存在configurationCache不会读取最新的配置，并且fileConfiguration的轮询获取最新配置被关闭了,看了一下之前存在这个pr: #3991 , 曾今我也被pr里面的问题疑惑过...，不过我觉得可以换一种方式解决一下.

Currently in the spring boot environment, seata cannot sense changes in environment variables. Even if the configuration center has pushed the configuration to the application environment, the configuration center here is not a separate configuration center for seata. I feel that this situation is very common. I I took a look because the configurationCache will not read the latest configuration, and the polling of fileConfiguration to obtain the latest configuration is turned off. See: #3991. I have also I was confused by #3991, but I think it can be solved in another way.

How it could be?

A clear and concise description of what you want to happen. You can explain more about input of the feature, and output of it.

Other related information

Add any other context or screenshots about the feature request here.

[funky-eyes]

实际上的根本性问题是seata的配置中心实现不是以一种结合模式，比如seatafile+spring+远程配置中心，而是多选一的形式，导致了使用file的时候强行通过代理来与spring进行结合，而不是在spring下以spring schema扩展，springboot的SpringApplicationRunListener等拿到environment将其作为一个扩展的配置中心视线，以链式注册到某个configuration，按照优先级排序，从哪读取到非空值后则截止。还有你所说的#3991 的问题，springboot+file下并不会起到动态刷新配置的作用，所以就把它关闭了。还有一点就是，所有需要动态的配置都是需要监听的，spring貌似没有提供一个刷新事件的event对外（springcloud是有的）
In fact, the fundamental problem is that the configuration center implementation of seata is not in a combination mode, such as seatafile + spring + remote configuration center, but in the form of multiple choices, which leads to the use of file when forcibly combining with spring through a proxy, instead of extending with spring schema under spring, the SpringApplicationRunListener of springboot, etc. get it as an extended configuration center line of sight, register with a configuration in a chain, sort by priority, and cut off after reading the non-null value from where. There is also the problem of #3991 you mentioned, springboot + file does not play a role in dynamically refreshing the configuration, so it is closed. Another point is that all dynamic configurations need to be listened to, and spring does not seem to provide a refresh event external (springcloud has it)

[laywin]

实际上的根本性问题是seata的配置中心实现不是以一种结合模式，比如seatafile+spring+远程配置中心，而是多选一的形式，导致了使用file的时候强行通过代理来与spring进行结合，而不是在spring下以spring schema扩展，springboot的SpringApplicationRunListener等拿到environment将其作为一个扩展的配置中心视线，以链式注册到某个configuration，按照优先级排序，从哪读取到非空值后则截止。还有你所说的#3991 的问题，springboot+file下并不会起到动态刷新配置的作用，所以就把它关闭了。还有一点就是，所有需要动态的配置都是需要监听的，spring貌似没有提供一个刷新事件的event对外（springcloud是有的） In fact, the fundamental problem is that the configuration center implementation of seata is not in a combination mode, such as seatafile + spring + remote configuration center, but in the form of multiple choices, which leads to the use of file when forcibly combining with spring through a proxy, instead of extending with spring schema under spring, the SpringApplicationRunListener of springboot, etc. get it as an extended configuration center line of sight, register with a configuration in a chain, sort by priority, and cut off after reading the non-null value from where. There is also the problem of #3991 you mentioned, springboot + file does not play a role in dynamically refreshing the configuration, so it is closed. Another point is that all dynamic configurations need to be listened to, and spring does not seem to provide a refresh event external (springcloud has it)

理解，相当于seata的配置不是多propertySource组合的方式，我测试了一下springboot+file可以动态刷新额, FileConfiguration里面的事件监听，这个操作 ConfigurationFactory.getInstance().getLatestConfig， ConfigurationFactory.getInstance()这个会包两层代理，ConfigurationCache->SpringBootConfigurationProvider, getLatestConfig()会获取最新的配置.

Understand, the configuration equivalent to seata is not a combination of multiple propertySources. I tested that springboot+file can dynamically refresh the amount, and the event monitoring in FileConfiguration. This operation ConfigurationFactory.getInstance().getLatestConfig, ConfigurationFactory.getInstance() will include two Layer proxy, ConfigurationCache->SpringBootConfigurationProvider, getLatestConfig() will get the latest configuration.

[funky-eyes]

你说的SpringBootConfigurationProvider不是动态刷新，实时获取。
You're talking about SpringBootConfigurationProvider not dynamic refresh, real-time fetch.

[laywin]

FileConfiguration 会去驱动拉取最新的配置啊
FileConfiguration will go to the driver to pull the latest configuration.

[funky-eyes]

spring貌似没有提供一个刷新事件的event对外，怎么能说是动态刷新？现在就是每秒实时获取
Spring doesn't seem to provide a refresh event. How can it be said to be a dynamic refresh? Now it is fetched in real time every second

[laywin]

是的，spring boot没有，springcloud有，我说的是FileConfiguration动态轮询的那个操作，可以拉取到最新的配置，但现在被关闭了.
Yes, spring boot does not have it. I am talking about the operation of dynamic polling of FileConfiguration. It can pull the latest configuration, but it is closed now.

[funky-eyes]

是的，spring boot没有，springcloud有，我说的是FileConfiguration动态轮询的那个操作，可以拉取到最新的配置，但现在被关闭了. Yes, spring boot does not have it. I am talking about the operation of dynamic polling of FileConfiguration. It can pull the latest configuration, but it is closed now.

那个问题还是因为无法感知spring容器已经关闭或者热更新下容器刷新了，导致那个定时任务一直在跑，一直抛出异常，实际上可以再spring下监听ContextRefreshedEvent或ContextClosedEvent去做到关闭这个轮询的线程。当初认为seata本身就支持三方的配置中心和自定义扩展的配置中心，所以不需要搞的太复杂去对接这些事件
The problem is still because I can't perceive that the spring container has been closed or the container has been refreshed under hotfix, resulting in the scheduled task running all the time and throwing exceptions. In fact, I can listen to ContextRefreshedEvent or ContextClosedEvent under spring to close the Polling thread. At first, I thought that seata itself supports the three-party configuration center and the customized extended configuration center, so there is no need to make it too complicated to connect these events

[laywin]

我觉得可以，监听一下 ContextClosedEvent 事件，把 file.listener.enabled 环境变量设置进去，就能把任务停下来了，主要是目前 spring + 远程配置中心的这种应用情况还是比较普遍. 你的建议了？

I think it's ok,listen to the ContextClosedEvent event and set the file.listener.enabled environment variable to stop the task. This is mainly because the current application of spring + remote configuration center is still relatively common. your suggestion？

[funky-eyes]

我觉得可以，监听一下 ContextClosedEvent 事件，把 file.listener.enabled 环境变量设置进去，就能把任务停下来了，主要是目前 spring + 远程配置中心的这种应用情况还是比较普遍. 你的建议了？

I think it's ok,listen to the ContextClosedEvent event and set the file.listener.enabled environment variable to stop the task. This is mainly because the current application of spring + remote configuration center is still relatively common. your suggestion？

我觉得可以，可以先这么做。
I think it's okay to do this first.

[laywin]

我看了一下， #3991 这个问题实际在 1.5.x的版本里面没了，原因是在1.4.x的版本里面, SpringBootConfigurationProvider 有一个操作会去getBean, 这个操作在容器关闭的时候会报错. 不过还是加上了 在 收到 ContextClosedEvent 时候 去设置 file.listener.enabled 变量的操作，原因在于尽可能快的推出fileListener拉取配置的操作.

I took a look and found that the problem #3991 is actually gone in version 1.5.x. The reason is that in version 1.4.x, SpringBootConfigurationProvider has an operation to getBean, which will report an error when the container is closed. It is still added to set the file.listener.enabled variable when receiving the ContextClosedEvent. The reason is that it is necessary to quickly launch the fileListener pull configuration operation.