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