正文
-
一套完整统一的API，可用于基于编程或注解方式的配置访问，适用于Java SE和EE环境；
-
支持像Spring和OSGi这样的框架；
-
支持动态增强（允许我们引入额外的属性源）；
-
过滤可访问的key/value，这种过滤可以按照单个属性来进行，也可以按照完整的配置来进行。这样的话，就允许key和value进行变更（例如，密码要进行掩码处理）、省略或添加。或者，我们也可以基于访问控制列表来进行访问的限制；
-
默认情况下，配置会组织成PropertySource的有序列表，每个PropertySource都会有一个顺序值。PropertySource可以提供任意类型的属性，比如系统属性、环境属性、基于文件的属性，以及任意种类的来源和格式。具有较高顺序值的PropertySource将会覆盖（默认情况下）具有较低顺序值的PropertySource所提供的属性条目（每个PropertySource会实现针对某种资源的映射）；
-
正如前面所介绍的，针对相同的key，重要性较高的值（由具有较高顺序值的PropertySource所提供的值）会覆盖掉重要性较低的值。但在有些场景下，由用户来自定义行为会更加合适，为了支持这些场景，我们允许用户自定义联合策略，从而实现更为灵活的覆盖机制。例如，在配置
List
值的时候，我们可以定义一种行为来联合两个值
“a, b”
和
“c, d, e”
，从而形成
“a, b, c, d, e”
；
-
在配置文件中，支持占位符，例如
${sys:a.sys.property}、${url:config.server:8090/v1/a.b.c}、${conf:cross.ref}
；
-
支持多种配置格式，比如Yaml、Json、属性文件等；
-
能够与各种新的、特定的配置后端集成，比如etcd和Consul；
-
支持动态和灵活的资源定位，例如在数据库中、在Consul或etcd中、在文件中等；
-
支持动态的配置处理、事件以及可变配置。
尚未发布的特性包括（计划在0.3-incubating版本会涵盖）：
接下来，让我们看一下“配置一次，到处运行”的一些样例。使用Tamaya来实现可配置的组件通常会包含如下步骤：
-
组件的实现；
-
决定可配置的方面；
-
定义key以及合理的默认值，从而能够支持“约定优于配置”；
-
将提供集成功能的Tamaya库添加到你的目标运行时环境中，这种环境可能是Java EE servlet容器或Spring Boot应用；
-
通过硬编码的默认值来使用组件，随后可以通过正常的实现类来运行，不需要任何额外的配置。借助Tamaya，可以文档化和观察我们的配置，通过添加某项简单的依赖，我们就可以指定生效的文件格式或配置后端。
我们来考虑一个简单的样例：假设我们正在构建一个组件，这个组件能够提供某个应用的售后支持通讯录信息。
SupportContact
组件的定义如下所示：
为了配置这个类，我们可以实现一个构造器来执行配置逻辑：
