嗨

我了解这一点的需要，当您有太多应用服务器并且需要更新特定属性而又不使服务器退回时，它会很有用。

可以有两个选择-

如果用例中的属性始终是自定义属性，则可以创建简单的项目类型并将此类值存储在DB中，而不是存储在属性文件中。 编写服务，利用缓存，您将能够采用集中式方式维护此类属性。 代替ConfigurationService，使用您的新服务。

另一个选择是查看 ConfigIntf.ConfigChangeListener 。 您基本上可以实现自己的 ConfigChangeListener 。 您将需要向将实例注册为ConfigChangeListener的bean提供一个初始化方法。

  public void init（）{
      Registry.getCurrentTenant（）。getConfig（）。registerConfigChangeListener（this）;
  }

  

现在是最困难的部分了：)，在覆盖的 configChanged（String key，String value）方法中，您需要将消息广播到其他节点以更新其中的密钥值 他们的JVM。

我还没有自己实现，但是研究平台代码，这是我要采取的方向：

• 创建一个实现 BroadcastMessageListener 接口的类，将其称为 ConfigChangeBroadcastHandler 。

• 在您的班级中插入 BroadcastService 。

• 在构造函数中，通过调用 BroadcastService#registerBroadcastListener

将您的类注册为广播侦听器。

• 公开一个名为 sendMessage 的公共方法，您可以在其中将键/值作为输入。 此方法将从自定义 ConfigChangeListener 中的 configChanged 方法中调用。

• 在将您的密钥（值）包装在RawMessage实例中时，调用BroadcastService#send。 ->应该注意将更改广播到集群中的所有节点

• 实施 processMessage 方法，在该方法中，您将 RawMessage 解析为键/值，然后调用 Config.setParameter（键，值），它将更新接收事件的节点的JVM中的属性。

同样，我尚未实现此用例，但这是[Cache] InvalidationBroadcastHandler 的工作方式。 而且，我认为无需多说，在服务器重新启动后，该值将恢复为原来的值。

干杯。