Java实现配置加载机制
前言
现如今几乎大多数Java应用，例如我们耳熟能详的tomcat,struts2,netty...等等数都数不过来的软件，
要满足通用性，都会提供配置文件供使用者定制功能。
甚至有一些例如Netty这样的网络框架，几乎完全就是由配置驱动，这样的软件我们也通常称之为"微内核架构"的软件。
你把它配置成什么，它就是什么。
Itiswhatyouconfigureittobe.
最常见的配置文件格式是XML,Properties等等文件。
本文探讨加载配置中最通用也是最常见的场景，那就是把一个配置文件映射成Java里的POJO对象.
并探讨如何实现不同方式的加载，例如，有一些配置是从本地XML文件里面加载的，而有一些配置需要从本地Properties文件加载，更有甚者，有一些配置需要通过网络加载配置。
如何实现这样一个配置加载机制，让我们拥有这个机制后，不会让加载配置的代码散布得到处都是，并且可扩展，可管理。
配置加载器
首先，我们需要一个配置加载器，而这个配置加载器是可以有多种不同的加载方式的，因此，我们用一个接口来描述它，如下所示：
/**
*
*
*@authorBean
*@date2016年1月21日上午11:47:12
*@version1.0
*
*/
publicinterfaceIConfigLoader<T>{
/**
*loadtheconfigtypedbyT
*
*@return
*@throwsConfigException
*/
publicTload()throwsConfigException;
}
可是，为什么我们需要在这个接口上声明泛型<T>?
很明显，当我们要使用一个配置加载器时，你得告诉这个配置加载器你需要加载后得到什么结果。
例如，你希望加载配置后得到一个AppleConfig对象，那么你就可以这么去使用上述定义的接口：
IConfigLoader<AppleConfig>loader=newAppleConfigLoader<AppleConfig>(); AppleConfigconfig=loader.load();
于是你将配置文件里的信息转化成了一个AppleConfig对象，并且你能得到这个AppleConfig对象实例。
到目前，貌似只要我们的AppleConfigLoader里面实现了怎么加载配置文件的具体劳动，我们就可以轻易加载配置了。
可以这么说，但是不是还没有考虑到，配置可能通过不同的方式加载呢，比如通过Properties加载，通过dom方式加载，通过sax方式加载，或者通过某些第三方的开源库来加载。
因此，除了配置加载器，我们还需要另外一种角色，配置加载方式的提供者。暂且，我们就叫它IConfigProvider。
配置加载方式的提供者
配置加载方式的提供者可以提供一种加载方式给配置加载器，换言之，提供一个对象给配置加载器。
如果通过dom方式加载，那么提供者提供一个Document对象给加载器。
如果通过Properties方式加载，那么提供者提供一个Properties对象给加载器
如果通过第三方类库提供的方式加载，比如apache-commons-digester3(tomcat的配置加载)，那么提供者提供一个Digester对象给加载器
提供者的职责就是提供，仅此而已，只提供配置加载器所需要的对象，但它本身并不参与配置加载的劳动。
我们用一个接口IConfigProvider来定义这个提供者
/**
*
*
*@authorBean
*@date2016年1月21日上午11:54:28
*@version1.0
*
*/
publicinterfaceIConfigProvider<T>{
/**
*provideaconfigsourceusedforloadingconfig
*
*@return
*@throwsConfigException
*/
publicTprovide()throwsConfigException;
}
这里为什么又会有<T>来声明泛型呢？
如果需要一个提供者，那么至少得告诉这个提供者它该提供什么吧。
因此，一个提供者会提供什么，由这个来决定。
同时，到这里，我们可以先建造一个工厂，让它来生产特定的提供者:
/**
*
*
*@authorBean
*@date2016年1月21日上午11:56:28
*@version1.0
*
*/
publicclassConfigProviderFactory{
privateConfigProviderFactory(){
thrownewUnsupportedOperationException("Unabletoinitializeafactoryclass:"
+getClass().getSimpleName());
}
publicstaticIConfigProvider<Document>createDocumentProvider(StringfilePath){
returnnewDocumentProvider(filePath);
}
publicstaticIConfigProvider<Properties>createPropertiesProvider(StringfilePath){
returnnewPropertiesProvider(filePath);
}
publicstaticIConfigProvider<Digester>createDigesterProvider(StringfilePath){
returnnewDigesterProvider(filePath);
}
}
可以开始实现具体配置加载器了?
还不行!
到这里，假设我们有一个配置文件，叫apple.xml。而且我们要通过DOM方式把这一份apple.xml加载后变成AppleConfig对象。
那么，首先我要通过提供者工厂给我制造一个能提供Document的提供者。然后拿到这个提供者，我就可以调用它的provide方法来获得Document对象，
有了document对象，那么我就可以开始来加载配置了。
可是，如果要加载BananaConfig、PearConfig.......呢，其步骤都是一样的。因此我们还要有一个抽象类，来实现一些默认的共同行为。
/**
*
*
*@authorBean
*@date2016年1月21日上午11:59:19
*@version1.0
*
*/
publicabstractclassAbstractConfigLoader<T,U>implementsIConfigLoader<T>{
protectedIConfigProvider<U>provider;
protectedAbstractConfigLoader(IConfigProvider<U>provider){
this.provider=provider;
}
/*
*@seeIConfigLoader#load()
*/
@Override
publicTload()throwsConfigException{
returnload(getProvider().provide());
}
publicabstractTload(UloaderSource)throwsConfigException;
protectedIConfigProvider<U>getProvider(){
returnthis.provider;
}
}
每个配置加载器都有一个带参数构造器，接收一个Provider。
泛型指明了我要加载的是AppleConfig还是BananConfig，泛型<U>指明了要用什么加载方式加载，是Document呢，还是Properties，或者其他。
实战运用实例
有一份菜市场配置文件market.xml，配置了菜市场的商品，里面有两种商品，分别是苹果和鸡蛋。
<market> <apple> <color>red</color> <price>100</price> </apple> <egg> <weight>200</weight> </egg> </market>
另外还有一份关于各个档口老板名字的配置文件，owner.properties
port1=SteveJobs port2=BillGates port3=KobeBryant
我们先定义好如下类:
MarketConfig.java
/**
*
*
*@authorBean
*@date2016年1月21日下午11:03:37
*@version1.0
*
*/
publicclassMarketConfig{
privateAppleConfigappleConfig;
privateEggConfigeggConfig;
privateOwnerConfigownerConfig;
publicAppleConfiggetAppleConfig(){
returnappleConfig;
}
publicvoidsetAppleConfig(AppleConfigappleConfig){
this.appleConfig=appleConfig;
}
publicEggConfiggetEggConfig(){
returneggConfig;
}
publicvoidsetEggConfig(EggConfigeggConfig){
this.eggConfig=eggConfig;
}
publicOwnerConfiggetOwnerConfig(){
returnownerConfig;
}
publicvoidsetOwnerConfig(OwnerConfigownerConfig){
this.ownerConfig=ownerConfig;
}
}
AppleConfig.java
/**
*
*
*@authorBean
*@date2016年1月21日下午11:03:45
*@version1.0
*
*/
publicclassAppleConfig{
privateintprice;
privateStringcolor;
publicvoidsetPrice(intprice){
this.price=price;
}
publicintgetPrice(){
returnthis.price;
}
publicvoidsetColor(Stringcolor){
this.color=color;
}
publicStringgetColor(){
returnthis.color;
}
}
EggConfig.java
/**
*
*
*@authorBean
*@date2016年1月21日下午11:03:58
*@version1.0
*
*/
publicclassEggConfig{
privateintweight;
publicvoidsetWeight(intweight){
this.weight=weight;
}
publicintgetWeight(){
returnthis.weight;
}
}
OwnerConfig.java
/**
*
*
*@authorBean
*@date2016年1月21日下午11:04:06
*@version1.0
*
*/
publicclassOwnerConfig{
privateMap<String,String>owner=newHashMap<String,String>();
publicvoidaddOwner(StringportName,Stringowner){
this.owner.put(portName,owner);
}
publicStringgetOwnerByPortName(StringportName){
returnthis.owner.get(portName);
}
publicMap<String,String>getOwners(){
returnCollections.unmodifiableMap(this.owner);
}
}
这个例子有两种配置加载方式，分别是Dom和Properties加载方式。
所以我们的提供者建造工厂需要制造两种提供者provider.
而且需要定义2个配置加载器，分别是:
OwnerConfigLoader
/**
*
*
*@authorBean
*@date2016年1月21日下午11:24:50
*@version1.0
*
*/
publicclassOwnerConfigLoaderextendsAbstractConfigLoader<OwnerConfig,Properties>{
/**
*@paramprovider
*/
protectedOwnerConfigLoader(IConfigProvider<Properties>provider){
super(provider);
}
/*
*@seeAbstractConfigLoader#load(java.lang.Object)
*/
@Override
publicOwnerConfigload(Propertiesprops)throwsConfigException{
OwnerConfigownerConfig=newOwnerConfig();
/**
*利用props，设置ownerConfig的属性值
*
*此处代码省略
*/
returnownerConfig;
}
}
然后是MarketConfigLoader
importorg.w3c.dom.Document;
/**
*
*
*@authorBean
*@date2016年1月21日下午11:18:56
*@version1.0
*
*/
publicclassMarketConfigLoaderextendsAbstractConfigLoader<MarketConfig,Document>{
/**
*@paramprovider
*/
protectedMarketConfigLoader(IConfigProvider<Document>provider){
super(provider);
}
/*
*AbstractConfigLoader#load(java.lang.Object)
*/
@Override
publicMarketConfigload(Documentdocument)throwsConfigException{
MarketConfigmarketConfig=newMarketConfig();
AppleConfigappleConfig=newAppleConfig();
EggConfigeggConfig=newEggConfig();
/**
*在这里处理document,然后就能得到
*AppleConfig和EggConfg
*
*此处代码省略
*/
marketConfig.setAppleConfig(appleConfig);
marketConfig.setEggConfig(eggConfig);
/**
*由于OwnerConfig是需要properties方式来加载，不是xml
*所以这里要新建一个OwnerConfigLoader，委托它来加载OwnerConfig
*/
OwnerConfigLoaderownerConfigLoader=newOwnerConfigLoader(ConfigProviderFactory.createPropertiesProvider(YOUR_FILE_PATH));
OwnerConfigownerConfig=ownerConfigLoader.load();
marketConfig.setOwnerConfig(ownerConfig);
returnmarketConfig;
}
}
然后，我们在应用层面如何获取到MarketConfig呢
MarketConfigLoadermarketConfigLoader=newMarketConfigLoader(ConfigProviderFactory.createDocumentProvider(YOUR_FILE_PATH));
MarketConfigmarketConfig=marketConfigLoader.load();
也许有个地方会人奇怪，明明有四个配置类，为什么只有2个配置加载器呢。
因为MarketConfig、EggConfig和AppleConfig，都是从同一个xml配置文件里面加载，所以只要一个Document对象，通过MarketConfigLoader就可以全部加载。
而OwnerConfig是不同的加载方式，所以需要另外一个加载器。
尾声
本文提出的配置加载机制，并不能够实际帮忙加载配置，这事应该留给DOM，SAX，以及其他一些开源库如dom4j，Digester去做。
但本文提出的配置加载机制能够让配置加载机制更灵活，容易扩展，并且能够集成多种配置加载方式，融合到一个机制进来，发挥各自有点。
实际上，有些软件经常需要同时从多种不同格式的配置文件里面加载配置，例如struts2，以及我最近在研究并被气到吐血的某国产开源数据库中间件软件，
如果没有一套完整的配置加载机制，那么代码会比较散乱，可维护性不高。容易使人吐血。