澳门新浦京8455comStruts2(三)配置详解

澳门新浦京8455com 3

前言

现如今几乎大多数Java应用,例如我们耳熟能详的tomcat, struts2,
netty…等等数都数不过来的软件,要满足通用性,都会提供配置文件供使用者定制功能。

甚至有一些例如Netty这样的网络框架,几乎完全就是由配置驱动,这样的软件我们也通常称之为”微内核架构”的软件。你把它配置成什么,它就是什么。

It is what you configure it to be.

最常见的配置文件格式是XML, Properties等等文件。

本文探讨加载配置中最通用也是最常见的场景,那就是把一个配置文件映射成Java里的POJO对象.

并探讨如何实现不同方式的加载,例如,有一些配置是从本地XML文件里面加载的,而有一些配置需要从本地Properties文件加载,

更有甚者,有一些配置需要通过网络加载配置。

如何实现这样一个配置加载机制,让我们拥有这个机制后,不会让加载配置的代码散布得到处都是,并且可扩展,可管理。

一、概述

  Struts2提供了多种可选的配置文件形式。

澳门新浦京8455com 1

澳门新浦京8455com 2

  其中,struts-default.xml和default.properties是框架级别的配置文件,这两个文件在Struts的核心JAR包中,它们将在应用程序启动时被struts的初始化程序读取并加载。而struts.xml和struts.properties是应用级别的配置文件,它的结构与框架级别的相同,但是其中的定义会覆盖框架级别的定义。除此之外,还可以通过Struts2的插件来进行应用级别的配置定义,这一配置定义在插件所在JAR包的根目录,并以struts-plugin.xml的文件名形式出现。

  配置文件的加载顺序:

public void init() 
{
        if (configurationManager == null) {
            configurationManager = createConfigurationManager(DefaultBeanSelectionProvider.DEFAULT_BEAN_NAME);
        }
        try {
            init_FileManager();
            init_DefaultProperties(); // [1]
            init_TraditionalXmlConfigurations(); // [2]
            init_LegacyStrutsProperties(); // [3]
            init_CustomConfigurationProviders(); // [5]
            init_FilterInitParameters() ; // [6]
            init_AliasStandardObjects() ; // [7]
            Container container = init_PreloadConfiguration();
             ...
        }    
}

  从上段代码可以分析出,struts2配置文件的加载顺序为:default.properties->struts-defaultxml->struts-plugin.xml->struts.xml->struts.properties->struts.locale。

配置加载器

首先,我们需要一个配置加载器,而这个配置加载器是可以有多种不同的加载方式的,因此,我们用一个接口来描述它,如下所示:

/**
 * 
 *
 * @author Bean
 * @date 2016年1月21日 上午11:47:12
 * @version 1.0
 *
 */
public interface IConfigLoader<T> {

    /**
     * load the config typed by T
     *
     * @return
     * @throws ConfigException
     */
    public T load() throws ConfigException;
}

可是,为什么我们需要在这个接口上声明泛型 <T> ?

很明显,当我们要使用一个配置加载器时,你得告诉这个配置加载器你需要加载后得到什么结果。

例如,你希望加载配置后得到一个 AppleConfig
对象,那么你就可以这么去使用上述定义的接口:

    IConfigLoader<AppleConfig> loader = new AppleConfigLoader<AppleConfig>();
    AppleConfig config = loader.load();

于是你将配置文件里的信息转化成了一个AppleConfig对象,并且你能得到这个AppleConfig对象实例。

到目前,貌似只要我们的 AppleConfigLoader
里面实现了怎么加载配置文件的具体劳动,我们就可以轻易加载配置了。

可以这么说,但是不是还没有考虑到,配置可能通过不同的方式加载呢,比如通过Properties加载,通过dom方式加载,通过sax方式加载,或者通过某些第三方的开源库来加载。

因此,除了 配置加载器
,我们还需要另外一种角色,配置加载方式的提供者。暂且,我们就叫它IConfigProvider。

二、Struts配置元素定义

  Struts2框架中的XML文件的配置元素定义是Properties文件的配置元素定义的超集,凡是能够在Properties文件中定义的配置元素,我们都可以在XML中找到相应的配置方式代替。下面我们从struts-default.xml文件入手,分析Struts配置元素的定义,部分源码如下:

<struts>
    <constant name="struts.excludedPackageNamePatterns" value="^java.lang..*,^ognl.*,^(?!javax.servlet..+)(javax..+)" />
    <constant name="struts.dispatcher.errorHandler" value="struts" />
    <!--  Silly workarounds for OGNL since there is currently no way to flush its internal caches -->
    <bean type="ognl.PropertyAccessor" name="java.util.ArrayList" class="com.opensymphony.xwork2.ognl.accessor.XWorkListPropertyAccessor" />
    <bean type="ognl.PropertyAccessor" name="java.util.HashSet" class="com.opensymphony.xwork2.ognl.accessor.XWorkCollectionPropertyAccessor" />
    <bean type="ognl.PropertyAccessor" name="java.util.HashMap" class="com.opensymphony.xwork2.ognl.accessor.XWorkMapPropertyAccessor" />
    <!-- 此处省略 -->
    <bean type="com.opensymphony.xwork2.security.ExcludedPatternsChecker" name="struts" class="com.opensymphony.xwork2.security.DefaultExcludedPatternsChecker" scope="default" />
    <bean type="com.opensymphony.xwork2.security.AcceptedPatternsChecker" name="struts" class="com.opensymphony.xwork2.security.DefaultAcceptedPatternsChecker" scope="default" />
    <package name="struts-default" abstract="true">
        <result-types>
            <result-type name="chain" class="com.opensymphony.xwork2.ActionChainResult"/>
            <result-type name="dispatcher" class="org.apache.struts2.dispatcher.ServletDispatcherResult" default="true"/>
            <result-type name="freemarker" class="org.apache.struts2.views.freemarker.FreemarkerResult"/>
              <!-- 此处省略 -->
        </result-types>
        <interceptors>
            <interceptor name="alias" class="com.opensymphony.xwork2.interceptor.AliasInterceptor"/>
            <interceptor name="autowiring" class="com.opensymphony.xwork2.spring.interceptor.ActionAutowiringInterceptor"/>
            <interceptor name="chain" class="com.opensymphony.xwork2.interceptor.ChainingInterceptor"/>
            <interceptor name="conversionError" class="org.apache.struts2.interceptor.StrutsConversionErrorInterceptor"/>
           <!-- 此处省略 -->
            <!-- Sample validation and workflow stack -->
            <interceptor-stack name="validationWorkflowStack">
                <interceptor-ref name="basicStack"/>
                <interceptor-ref name="validation"/>
                <interceptor-ref name="workflow"/>
            </interceptor-stack>
            <!-- Sample file upload stack -->
            <interceptor-stack name="fileUploadStack">
                <interceptor-ref name="fileUpload"/>
                <interceptor-ref name="basicStack"/>
            </interceptor-stack>
           <!-- 此处省略 -->
       </interceptors>
        <default-interceptor-ref name="defaultStack"/>
        <default-class-ref class="com.opensymphony.xwork2.ActionSupport" />
    </package>
</struts>

  1.  bean节点

  bean节点是一个用于描述接口及其实现类映射关系的节点,Struts2在框架级别实现了一个对象容器,并将配置文件中所有的bean节点所定义的对象纳入容器之中管理。Struts通过这个容器在框架级别负责这些对象的创建、销毁以及依赖关系的处理。

  2.  constant节点

  该节点主要用于定义Struts2运行时的参数

  3.  package节点

  该节点包含了众多子节点,ResultType、Interceptor、InterceptorStack、Action等,这些子节点均继承与XWork框架。package节点作用主要是定义一种映射关系,反映了框架如何与外部程序进行交互的过程。

  在package节点的属性中,name是唯一的标识符,namespace则从命名空间的角度为整个事件请求机制划分为不同的种类。package节点的extends属性允许package与package之间形成相应的继承关系,通过继承,子package自动获取父package的所有配置定义。

   4.  include节点

  include节点的主要作用是帮助我们管理Struts2的配置文件,实现配置文件的模块化。我们可以在应用级别的配置文件(struts.xml)里,将整个应用的配置根据一定的逻辑划分为若干个独立的配置文件,以便模块化管理和团队开发。

<?xml version="1.0" encoding="UTF-8" ?>
<!DOCTYPE struts PUBLIC
    "-//Apache Software Foundation//DTD Struts Configuration 2.3//EN"
    "http://struts.apache.org/dtds/struts-2.3.dtd">
<struts>
    <constant name="struts.enable.DynamicMethodInvocation" value="false" />
    <constant name="struts.devMode" value="true" />
    <package name="default" namespace="/" extends="struts-default">
        <action name="index">
            <result type="redirectAction">
                <param name="actionName">HelloWorld</param>
                <param name="namespace">/example</param>
            </result>
        </action>
    </package>

    <include file="example.xml"/>
    <!-- Add packages here -->
</struts>

  struts.xml是Struts
2框架的核心配置文件,主要用于配置和管理开发人员编写的action。在这个配置文件中可以配置作用于action的拦截器、action和result的映射等。通常struts.xml从struts-default.xml继承默认的包定义。

  struts.xml文件的元素结构如下图:

  澳门新浦京8455com 3

  *:表示0个或多个元素

  ?:表示该元素是可选的

  +:表示该元素至少有一个或多个

  没有添加这三种符号表明这种元素是必需的。

  

配置加载方式的提供者

配置加载方式的提供者可以提供一种加载方式给配置加载器,换言之,提供一个
对象 给配置加载器。

  • 如果通过dom方式加载,那么 提供者 提供一个 Document 对象给
    加载器
  • 如果通过Properties方式加载,那么 提供者 提供一个 Properties
    对象给 加载器
  • 如果通过第三方类库提供的方式加载,比如apache-commons-digester3(tomcat的配置加载),那么
    提供者 提供一个 Digester 对象给 加载器

提供者的职责就是 提供
,仅此而已,只提供配置加载器所需要的对象,但它本身并不参与配置加载的劳动。

我们用一个接口 IConfigProvider 来定义这个 提供者

/**
 *
 *
 * @author Bean
 * @date 2016年1月21日 上午11:54:28
 * @version 1.0
 *
 */
public interface IConfigProvider<T> {

    /**
     * provide a config source used for loading config
     *
     * @return
     * @throws ConfigException
     */
    public T provide() throws ConfigException;
}

这里为什么又会有 <T> 来声明泛型呢?

如果需要一个提供者,那么至少得告诉这个提供者它该提供什么吧。

因此,一个提供者会提供什么,由这个来决定。

同时,到这里,我们可以先建造一个工厂,让它来生产特定的提供者:

/**
 *
 *
 * @author Bean
 * @date 2016年1月21日 上午11:56:28
 * @version 1.0
 *
 */
public class ConfigProviderFactory {

    private ConfigProviderFactory() {
        throw new UnsupportedOperationException("Unable to initialize a factory class : "
                + getClass().getSimpleName());
    }

    public static IConfigProvider<Document> createDocumentProvider(String filePath) {
        return new DocumentProvider(filePath);
    }

    public static IConfigProvider<Properties> createPropertiesProvider(String filePath) {
        return new PropertiesProvider(filePath);
    }

    public static IConfigProvider<Digester> createDigesterProvider(String filePath) {
            return new DigesterProvider(filePath);
    }
}

可以开始实现具体配置加载器了?

还不行!

到这里,假设我们有一个配置文件,叫apple.xml。而且我们要通过DOM方式把这一份apple.xml加载后变成AppleConfig对象。

那么,首先我要通过提供者工厂给我制造一个能提供Document的提供者。然后拿到这个提供者,我就可以调用它的provide方法来获得Document对象,有了document对象,那么我就可以开始来加载配置了。

可是,如果要加载BananaConfig、PearConfig…….呢,其步骤都是一样的。因此我们还要有一个抽象类,来实现一些默认的共同行为。

/**
 *
 *
 * @author Bean
 * @date 2016年1月21日 上午11:59:19
 * @version 1.0
 *
 */
public abstract class AbstractConfigLoader <T, U> implements IConfigLoader<T>{

    protected IConfigProvider<U> provider;

    protected AbstractConfigLoader(IConfigProvider<U> provider) {
        this.provider = provider;
    }

    /*
     * @see IConfigLoader#load()
     */
    @Override
    public T load() throws ConfigException {
        return load(getProvider().provide());
    }

    public abstract T load(U loaderSource) throws ConfigException;

    protected IConfigProvider<U> getProvider() {
        return this.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=Steve Jobs
port2=Bill Gates
port3=Kobe Bryant

我们先定义好如下类:MarketConfig.java

/**
 *
 *
 * @author Bean
 * @date 2016年1月21日 下午11:03:37
 * @version 1.0
 *
 */
public class MarketConfig {

    private AppleConfig appleConfig;
    private EggConfig eggConfig;
    private OwnerConfig ownerConfig;

    public AppleConfig getAppleConfig() {
        return appleConfig;
    }
    public void setAppleConfig(AppleConfig appleConfig) {
        this.appleConfig = appleConfig;
    }
    public EggConfig getEggConfig() {
        return eggConfig;
    }
    public void setEggConfig(EggConfig eggConfig) {
        this.eggConfig = eggConfig;
    }
    public OwnerConfig getOwnerConfig() {
        return ownerConfig;
    }
    public void setOwnerConfig(OwnerConfig ownerConfig) {
        this.ownerConfig = ownerConfig;
    }
}

AppleConfig.java

/**
 *
 *
 * @author Bean
 * @date 2016年1月21日 下午11:03:45
 * @version 1.0
 *
 */
public class AppleConfig {

    private int price;
    private String color;

    public void setPrice(int price) {
        this.price = price;
    }

    public int getPrice() {
        return this.price;
    }

    public void setColor(String color) {
        this.color = color;
    }

    public String getColor() {
        return this.color;
    }
}

EggConfig.java

/**
 *
 *
 * @author Bean
 * @date 2016年1月21日 下午11:03:58
 * @version 1.0
 *
 */
public class EggConfig {

    private int weight;

    public void setWeight(int weight) {
        this.weight = weight;
    }

    public int getWeight() {
        return this.weight;
    }
}

OwnerConfig.java

/**
 *
 *
 * @author Bean
 * @date 2016年1月21日 下午11:04:06
 * @version 1.0
 *
 */
public class OwnerConfig {

    private Map<String, String> owner = new HashMap<String, String>();

    public void addOwner(String portName, String owner) {
        this.owner.put(portName, owner);
    }

    public String getOwnerByPortName(String portName) {
        return this.owner.get(portName);
    }

    public Map<String, String> getOwners() {
        return Collections.unmodifiableMap(this.owner);
    }
}

这个例子有两种配置加载方式,分别是Dom和Properties加载方式。

所以我们的提供者建造工厂需要制造两种提供者provider.

而且需要定义2个配置加载器,分别是:

OwnerConfigLoader

/**
 *
 *
 * @author Bean
 * @date 2016年1月21日 下午11:24:50
 * @version 1.0
 *
 */
public class OwnerConfigLoader extends AbstractConfigLoader<OwnerConfig, Properties>{

    /**
     * @param provider
     */
    protected OwnerConfigLoader(IConfigProvider<Properties> provider) {
        super(provider);
    }

    /* 
     * @see AbstractConfigLoader#load(java.lang.Object)
     */
    @Override
    public OwnerConfig load(Properties props) throws ConfigException {
        OwnerConfig ownerConfig = new OwnerConfig();

        /**
         * 利用props,设置ownerConfig的属性值
         * 
         * 此处代码省略
         */
        return ownerConfig;
    }
}

然后是MarketConfigLoader

import org.w3c.dom.Document;

/**
 *
 *
 * @author Bean
 * @date 2016年1月21日 下午11:18:56
 * @version 1.0
 *
 */
public class MarketConfigLoader extends AbstractConfigLoader<MarketConfig, Document> {

    /**
     * @param provider
     */
    protected MarketConfigLoader(IConfigProvider<Document> provider) {
        super(provider);
    }

    /* 
     * AbstractConfigLoader#load(java.lang.Object)
     */
    @Override
    public MarketConfig load(Document document) throws ConfigException {

        MarketConfig marketConfig = new MarketConfig();
        AppleConfig appleConfig = new AppleConfig();
        EggConfig eggConfig = new EggConfig();
        /**
         * 在这里处理document,然后就能得到
         * AppleConfig和EggConfg
         * 
         * 此处代码省略
         */
        marketConfig.setAppleConfig(appleConfig);
        marketConfig.setEggConfig(eggConfig);

        /**
         * 由于OwnerConfig是需要properties方式来加载,不是xml
         * 所以这里要新建一个OwnerConfigLoader,委托它来加载OwnerConfig
         */

        OwnerConfigLoader ownerConfigLoader = new OwnerConfigLoader(ConfigProviderFactory.createPropertiesProvider(YOUR_FILE_PATH));
        OwnerConfig ownerConfig = ownerConfigLoader.load();

        marketConfig.setOwnerConfig(ownerConfig);

        return marketConfig;
    }
}

然后,我们在应用层面如何获取到MarketConfig呢

MarketConfigLoader marketConfigLoader = new MarketConfigLoader(ConfigProviderFactory.createDocumentProvider(YOUR_FILE_PATH));
MarketConfig marketConfig = marketConfigLoader.load();

也许有个地方会人奇怪,明明有四个配置类,为什么只有2个配置加载器呢。因为MarketConfig、EggConfig和AppleConfig,都是从同一个xml配置文件里面加载,所以只要一个Document对象,通过MarketConfigLoader就可以全部加载。

而OwnerConfig是不同的加载方式,所以需要另外一个加载器。

尾声

本文提出的配置加载机制,并不能够实际帮忙加载配置,这事应该留给DOM,SAX,以及其他一些开源库如dom4j,Digester去做。但本文提出的配置加载机制能够让配置加载机制更灵活,容易扩展,并且能够集成多种配置加载方式,融合到一个机制进来,发挥各自有点。

实际上,有些软件经常需要同时从多种不同格式的配置文件里面加载配置,例如struts2,以及我最近在研究并被气到吐血的某国产开源数据库中间件软件,如果没有一套完整的配置加载机制,那么代码会比较散乱,可维护性不高。容易使人吐血。

You can leave a response, or trackback from your own site.

Leave a Reply

网站地图xml地图