本文翻译自 – http://www.tigase.org/content/configuration-api
简介：
组件的配置API实际上非常简单，它包含两个方法：
|
1
2
|
Map getDefaults(Map params);
voidsetProperties(Map properties);
|
第一个方法从组件当中获取缺省配置，第二个方法为组件设置新的配置项。尽管看起来它们非常简单，但如果想高效得使用，还需要了解更多知识。
组件的启动顺序：
在我们深入了解全部的细节之前，需要首先知道组件的初始化顺序，组件是如何“获得生命”的，以及配置是何时被设置的。组件的加载和启动顺序是这样的：
- 组件类被加载，并使用无参的public构造函数产生一个实例。
- 组件实例的setName(compName)方法被调用，实例获得组件名称。在组件的生命周期中这个方法（应该）只被调用一次。
- 组件实例的start()方法被调用，组件启动了所有它自己的内部线程。start()和stop()方法可以在一起被调用多次，这通常用来让组件hold住和重新启动。通常情况开发者不需要关注这个方法，除非想覆写这个方法。
- 组件实例的getDefaults()方法被调用，Tigase服务器获得了所有该组建的缺省配置信息。在组件的生命周期中这个方法通常只被调用一次。
- 用户提供的配置信息与组件的缺省配置信息被合并。对于相同的配置项，用户提供的配置信息会覆写缺省值；对于不同的配置项，会保留各自的部分并进行累加。
- 组件实例的setProperties()方法被调用，组件获得最终配置信息。在组件的生命周期中，这个方法可以被多次调用。
- 组件实例的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 是保存用户数据的数据库实例（广义数据库）配置项键，这个实例可以被所有的组件共享使用，可以用来存储组件数据或访问用户数据。可以使用下面的代码来访问用户数据库实例：
12UserRepository user_repo;user_repo = (UserRepository) properties.get(SHARED_USER_REPO_PROP_KEY);
- SHARED_USER_REPO_POOL_PROP_KEY 是用户数据库连接池（广义数据库）的配置项键，在大多数情况用户数据库是SQL DB。可以使用下面的代码来访问用户数据库实例：
12UserRepository user_repo;user_repo = (UserRepository) properties.get(SHARED_USER_REPO_POOL_PROP_KEY);
- SHARED_AUTH_REPO_PROP_KEY 是认证数据库（广义数据库）的配置项键，组件在通常情况下不需要访问认证数据库，除非它们需要对用户进行认证，并且用户的认证信息与用户其他的信息保存在不同的数据库里面。可以通过下面的代码来访问认证数据库：
12UserAuthRepository auth_repo;auth_repo = (UserAuthRepository) properties.get(SHARED_AUTH_REPO_PROP_KEY);
来源：oschina
链接：https://my.oschina.net/u/811247/blog/209928