Tigase組件 – 配置API

本文翻譯自 – http://www.tigase.org/content/configuration-api

簡介：

組件的配置API實際上很是簡單，它包含兩個方法：

1 2	Map getDefaults(Map params); voidsetProperties(Map properties);

第一個方法從組件當中獲取缺省配置，第二個方法爲組件設置新的配置項。儘管看起來它們很是簡單，但若是想高效得使用，還須要瞭解更多知識。

組件的啓動順序：

在咱們深刻了解所有的細節以前，須要首先知道組件的初始化順序，組件是如何「得到生命」的，以及配置是什麼時候被設置的。組件的加載和啓動順序是這樣的：

1. 組件類被加載，並使用無參的public構造函數產生一個實例。
2. 組件實例的setName(compName)方法被調用，實例得到組件名稱。在組件的生命週期中這個方法（應該）只被調用一次。
3. 組件實例的start()方法被調用，組件啓動了全部它本身的內部線程。start()和stop()方法能夠在一塊兒被調用屢次，這一般用來讓組件hold住和從新啓動。一般狀況開發者不須要關注這個方法，除非想覆寫這個方法。
4. 組件實例的getDefaults()方法被調用，Tigase服務器得到了全部該組建的缺省配置信息。在組件的生命週期中這個方法一般只被調用一次。
5. 用戶提供的配置信息與組件的缺省配置信息被合併。對於相同的配置項，用戶提供的配置信息會覆寫缺省值；對於不一樣的配置項，會保留各自的部分並進行累加。
6. 組件實例的setProperties()方法被調用，組件得到最終配置信息。在組件的生命週期中，這個方法能夠被屢次調用。
7. 組件實例的initializationCompleted()方法被調用，在調用時組件知道了全局服務器的初始化過程已經完成。在服務器的啓動過程當中，這個方法只被調用一次（即全部的組件都完成了配置工做和初始化）。這個方法主要被network connection manager使用，當服務器的全部功能均可用以後，它會開始監聽網絡socket鏈接。

配置相關事項當中很重要的一點是：全部的組件都不會讀/請求/詢問配置信息，配置信息是由configuration manager推送給組件的。在服務器運行的時候，組件的setProperties()方法能夠屢次在任意時間被調用。這樣設計容許對服務器在運行時進行從新配置，開發者必定須要知道這一點，這樣纔可以在運行時對從新配置的數據進行正確處理。

配置API：

兩個關於配置的方法具備相同的入口參數Map<String, Object>，因此本質上組件的配置信息所有是鍵值對。Object對象能夠是：

• String
• Integer
• Long
• Double
• Boolean
• 或上述任意一種類型的數組

若是組件返回的缺省配置項是上面提到的任何一種數據類型，那麼setProperties()方法能夠確保設置的配置項必定是同一種類型。這對於開發者而言，在代碼中只須要有限得進行類型轉換。

getDefaults()

1	Map getDefaults(Map params);

這個方法在一般狀況下只被調用一次，就是在組件實例被建立以後。這個方法被用來從組件實例獲取一些缺省的配置信息，而後服務器能夠拿它們與用戶的提供的配置信息進行合併，產生缺省或最終的初始化配置信息。咱們建議這個方法返回全部的配置項及缺省值，這樣最終用戶在對組件進行配置的時候能夠看到全部的配置項，方便定位問題。組件的任何初始化代碼都不容許出如今該方法裏，開發者也不能想固然得認爲該方法只被調用一次。在任什麼時候候這個方法被調用，都只能返回組件的缺省配置，而不能返回經過setProperties()方法得到的最終配置信息。入口參數Map<String, Object>能夠包含一些「暗示」或者「預初始化」參數，它們會影響缺省配置的產生過程。這是由於一些組件的配置信息可能很複雜，並且這些配置信息具備不少的預設值或者會根據具體狀況自動進行優化。預設值能夠用來產生適合系統運行的缺省配置。若是組件 extend AbstractMessageReceiver，那麼這個方法的實現應該始終相似於下面的代碼：

1 2 3 4 5 6

@Override publicMap getDefaults(Map params) {   Map defs =super.getDefaults(params);   defs.put(CONF_ENTRY_KEY, conf_entry_val);   returndefs; }

setProperties()

1	voidsetProperties(Map<String, Object> properties);

這個方法用來爲組件設置配置信息。它能夠在服務器的生命週期中在任意時間被屢次調用。輸入的配置信息包含了全部經過調用getDefaults()方法所得到的缺省配置項，可是其中一些項的值可能因爲用戶錄入的配置數據被修改。若是組件extend AbstractMessageReceiver，那麼實現代碼可能爲：

1 2 3 4 5

@Override publicvoidsetProperties(Map properties) {   super.setProperties(properties);   intconf_entry_val = (Integer) properties.get(CONF_ENTRY_KEY); }

可能被用到的預設值

有一些會提供給全部的組件並被它們所用到的全局配置項。一般這些配置項是每一個組件都會用到的共享資源。

• SHARED_USER_REPO_PROP_KEY 是保存用戶數據的數據庫實例（廣義數據庫）配置項鍵，這個實例能夠被全部的組件共享使用，能夠用來存儲組件數據或訪問用戶數據。可使用下面的代碼來訪問用戶數據庫實例：

  1 2	UserRepository user_repo; user_repo = (UserRepository) properties.get(SHARED_USER_REPO_PROP_KEY);

• SHARED_USER_REPO_POOL_PROP_KEY 是用戶數據庫鏈接池（廣義數據庫）的配置項鍵，在大多數狀況用戶數據庫是SQL DB。可使用下面的代碼來訪問用戶數據庫實例：

  1 2	UserRepository user_repo; user_repo = (UserRepository) properties.get(SHARED_USER_REPO_POOL_PROP_KEY);

• SHARED_AUTH_REPO_PROP_KEY 是認證數據庫（廣義數據庫）的配置項鍵，組件在一般狀況下不須要訪問認證數據庫，除非它們須要對用戶進行認證，而且用戶的認證信息與用戶其餘的信息保存在不一樣的數據庫裏面。能夠經過下面的代碼來訪問認證數據庫：

  1 2	UserAuthRepository auth_repo; auth_repo = (UserAuthRepository) properties.get(SHARED_AUTH_REPO_PROP_KEY);

About these ads