春季物業熱裝

Question

在一個項目中，我有一個org.apache.commons.configuration.PropertiesConfiguration對象注冊為Bean，以提供具有熱重載功能的應用程序周圍的配置值。

示例：我定義了一個DataSource單例Bean。 然后，我創建了一個ReloadingDataSource對象，該對象包裝並委托給“真實的” DataSource ，並且每次配置文件更改時，它都可以以線程安全的方式重新創建它。

我想對簡單屬性值做類似的事情。
我想創建一個簡單的，支持Autowire對象，該對象將檢索委托給Apache PropertiesConfiguration Bean。

用法應類似於：

@Property("my.config.database")
private Property<String> database;

呼叫站點將只是：

final String databaseValue = database.get()

您會說，只需傳遞PropertiesConfiguration對象即可。 也許您是對的，但我想在此基礎上提供另一個抽象，一個更易於使用的抽象。

我知道，使用ProxyFactoryBean可以為方法調用創建AOP代理。 這是正確的道路，還是有更好的選擇？ 也許是純Spring AOP / AspectJ？

我不想使用Spring Cloud或類似的依賴項。

Answer 1

Spring Cloud將重新創建Bean，因此請記住您想出什么解決方案，如果您有另一個Bean，例如，在啟動時僅讀取一次該值，它將不會自行重新初始化，這就是Spring的問題。 Cloud Config負責。

據我了解，AOP僅在方法級別上起作用，因此您可以肯定地攔截對somebean.getFoo()的調用。 但是在somebean ，無法代理對變量本身的調用： somebean.foo 。 每當您的PropertiesConfiguration更改時，您都必須重置foo ，並且再次記住，如果其他任何需要foo的新值的情況，您都需要使用Spring Cloud來處理或使用它來解決。

為避免重新部署，在運行時更改內容所產生的開銷應認真考慮。 對於Netflix來說，這很有意義，因為它們有成千上萬的服務器。 但是對於較小的玩家，我看不出理由，這一決定增加了很多復雜性。 噩夢要考。

• 您是否在運行時測試更改配置，還是接受了風險並認為它可行？
• 您是否在用戶執行數據庫事務的負載下測試從A-> B的更改？
• 測試foo正在改變的其他提升條件嗎？

一些事情要考慮。