Webx3原理分析

最新推荐文章于 2021-06-25 11:36:44 发布

u011427518

最新推荐文章于 2021-06-25 11:36:44 发布

阅读量2.4k

点赞数 2

分类专栏： Java 文章标签： java

本文链接：https://blog.csdn.net/u011427518/article/details/51868050

版权

Java 专栏收录该内容

9 篇文章 0 订阅

订阅专栏

1 前言

抽空总结了Webx3框架，如有错误，欢迎指正！

2 背景知识

2.1 Maven

Maven主要解决了以下两个问题：

(1)、它为项目构建引入了一个统一的接口，抽象了构建的生命周期，并为生命周期中的绝大部分任务提供了实现的插件。你不需要去关心这个生命周期里发生的事情，只需要把代码放在指定的位置，执行一条命令，整个构建过程就完成了。

(2)、其次，它为Java世界里的依赖引入了经纬度（groupId和artifactId），不再需要下载指定版本的jar包、拷贝到lib目录这些事情，只需要定义我的项目依赖了哪些构件（artifact），Maven会自动帮你管理依赖，并将jar包下载到正确的位置上。

2.2 Servlet、HttpServlet及其Servlet生命周期

Servlet是java用于开发动态web资源的技术。是java web的基础。本质上，Servlet只是一个接口，或者说API，真正工作的是实现该接口的一个Java类的实例，由ServletContainer(常见的容器有Tomcat、Jboss)容器负责实例化。当请求到来时，容器将调用该实例的service方法。

HttpServlet指能够处理HTTP请求的servlet，它在原有Servlet接口上添加了一些与HTTP协议处理方法，它Servlet接口的功能更为强大。因此开发人员在编写Servlet时，通常应继承这个类，而避免直接去实现Servlet接口。HttpServlet在实现Servlet接口时，覆写了service方法，该方法体内的代码会自动判断用户的请求方式，如为GET请求，则调用HttpServlet的doGet方法，如为Post请求，则调用doPost方法。因此，开发人员在编写Servlet时，通常只需要覆写doGet或doPost方法，而不要去覆写service方法。

public interface Servlet {

        public void init(ServletConfig config) throws ServletException;

        public ServletConfig getServletConfig();

        public void service(ServletRequest req, ServletResponse res) throws ServletException, IOException;

        public String getServletInfo();

        public void destroy();
    }

Servlet程序是由WEB服务器调用，web服务器收到客户端的Servlet访问请求后：
(1)Web服务器首先检查是否已经装载并创建了该Servlet的实例对象。如果是，则直接执行第4步，否则，执行第2步

(2)装载并创建该Servlet的一个实例对象

(3)调用Servlet实例对象的init()方法

(4)创建一个用于封装HTTP请求消息的HttpServletRequest对象和一个代表HTTP响应消息的HttpServletResponse对
象，然后调用Servlet的service()方法并将请求和响应对象作为参数传递进去

(5)WEB应用程序被停止或重新启动之前，Servlet引擎将卸载Servlet，并在卸载之前调用Servlet的destroy()方法

2.3 DTD和Schema

DTD和Schema是两种常用的xml文件的约束文件，都是用来约定XML文件，目的是会提示使用者让使用者按照规定的格式去书写XML，验证XML文件有效性。主要的区别有一下几点：
（1）Schema遵循XML语法，学习成本低，不需要再学习新的语法；DTD和XML语法使用的是自己特殊的语法
（2）DTD只能指定元素含有文本，不定定义元素文本的类型，如字符型、整型、日期型、自定义类型等。Schema在这方面比DTD强大。
（3）Schema对命名空间的支持，如果出现两个相同的元素定义，使用命名空间可以完美的避免重复元素定义，而DTD不支持命名空间

下面就同一个XML文件，分别使用DTD和Schema约束，W3C官方给出的示例：

<?xml version="1.0"?>
<note>
    <to>George</to>
    <from>John</from>
    <heading>Reminder</heading>
    <body>Don‘t forget the meeting!</body>
</note>

DTD约束：

<!ELEMENT note (to, from, heading, body)>
<!ELEMENT to (#PCDATA)>
<!ELEMENT from (#PCDATA)>
<!ELEMENT heading (#PCDATA)>
<!ELEMENT body (#PCDATA)>

Schema约束：

<?xml version="1.0"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" targetNamespace="http://www.w3school.com.cn" xmlns="http://www.w3school.com.cn" elementFormDefault="qualified">

<xs:element name="note">
<xs:complexType>
    <xs:sequence>
        <xs:element name="to" type="xs:string"/>
        <xs:element name="from" type="xs:string"/>
        <xs:element name="heading" type="xs:string"/>
        <xs:element name="body" type="xs:string/>
   </xs:seuence>
</xs:complexType>
</xs:element>
</xs:schema>

2.4 日志框架和日志系统

(1)日志系统

最开始出现的是log4j，也是应用最广泛的日志系统，成为了目前java日志系统事实上的标准

JUL（java.util.logging.*)，JDK 1.4 自带的日志系统；JUL 并没有明显的优势来战胜Log4j，反而造成了标准的混乱——采用不同日志系统的应用程序无法和谐共存；

Logback，是较新的日志系统，它是 Log4j 的作者吸取多年的经验教训以后重新做出的一套系统；它的使用更方便，功能更强，而且性能也更高；Logback 不能单独使用,必须配合日志框架 SLF4J 来使用；

(2)日志框架

JUL 诞生以后，为了克服多种日志系统并存所带来的混乱，就出现了“日志框架”。日志框架本身不提供记录日志的功能，
它只提供了日志调用的接口。日志框架依赖于实际的日志系统如Logback、Log4j或 JUL 来产生真实的日志；使用日志框架的好处是：应用的部署者可以决定使用哪一种日志系统（Logback、Log4j 还是 JUL），或者在多种日志系统之间切换，而不需要更改应用的代码；

JCL（Jakarta Commons Logging），这是目前最流行的一个日志框架，由 Apache Jakarta 社区提供；一些框架和老应用（如 Spring 等）都依赖于 JCL；

SLF4J，这是一个最新的日志框架，由 Log4j 的作者推出；SLF4J 提供了新的 API，特别用来配合Logback的新功能。但 SLF4J同样兼容 Log4j；

3 Webx3基础知识

3.1 WebX3层次化设计

Webx框架可以划分成三个大层次，如下：

SpringExt：底层基于Spring开源框架，对其的拓展多数都是派生Spring原生类避免重复造轮子，兼容开源框架的所有功能，提供拓展组件的能力

Webx Framework：基于Servlet API，提供基础的服务，例如：初始化Spring、初始化日志、接收请求、错误处理、开发模式等。Webx Framework只和servlet及spring相关 ——它不关心Web框架中常见的一些服务，例如Action处理、表单处理、模板渲染等,Webx3接收完请求之后，处理完之后将请求转发到Turbine的Pipeline进行处理相应的功能

Webx Turbine：基于Webx Framework，实现具体的网页功能，例如：Action处理、表单处理、模板渲染等。

3.2 SpringExt

3.2.1 Spring2.0装配Bean方式，对于习惯于使用spring的开发人员是熟悉且习以为常的

<bean id="resourceLoadingService" class="com.alibaba...ResourceLoadingServiceImpl">
    <property name="mappings">
    <map>
        <entry key="/file" value-ref="fileLoader" />
        <entry key="/webroot" value-ref="webappLoader" />
    </map>
    </property>
</bean>
<bean id="fileLoader" class="com.alibaba...FileResourceLoader">
    <property name="basedir" value="${user.home}" />
</bean>
<bean id="webappLoader" class=" com.alibaba...WebappResourceLoader" />

存在的问题：

（1）没有检验机制，错误必须等到运行时才会被发现。装配者仅从spring配置文件中，无法直观地了解这个配置文件有没有写对？例如：应该从constructor args注入却配成了从properties注入；写错了property的名称；注入了错误的类型等等。

（2）无法了解更多约束条件。即使装配者查看API源码，也未必能了解到某些约束条件，例如：哪些properties是必须填写的，哪些是可选的，哪些是互斥的？

（3）当服务的实现被改变时，Spring配置文件可能会失败。因为Spring配置文件是直接依赖于服务的实现，而不是接口的。接口相对稳定，而实现是可被改变的。另一方面，这个问题也会阻碍服务提供者改进他们的服务实现。

3.2.2 Webx3，因为Spring 2.0支持用XML Schema来定义配置文件。同样的功能，用Spring Schema来定义，可能变成下面的样子：

<resource-loading id="resourceLoadingService" xmlns="http://www.alibaba.com/schema/services/resource-loading">
    <resource pattern="/file">
        <file-loader basedir="${user.home}" />
    </resource>
    <resource pattern="/webroot">
        <webapp-loader />
    </resource>

</resource-loading>

解决了spring2.0之前的以下问题：

（1）这个配置文件比起前面的Spring Beans风格的配置文件简单易读得多。因为在这个spring配置文件里，它所用的“语言”是“领域相关”的，也就是说，和ResourceLoadingService所提供的服务内容相关，而不是使用像bean、property这样的编程术语。这样自然易读得多。（最简单的往往是最容易维护的，并不认为这种方式更容易维护，代码可读性和可维护性降低，尤其在debug时需要先查具体的实现类）

（2）它是可验证的。你不需要等到运行时就能验证其正确性。任何一个支持XML Schema的标准XML编辑器，包括Eclipse自带的XML编辑器，都可以告诉你配置的对错，解决了spring bean2.0运行时才会报错的问题

（3）包含更多约束条件。例如，XML Schema可以告诉你，哪些参数是可选的，哪些是必须填的；参数的类型是什么等等。

（4）服务的实现细节对装配者隐藏。当服务实现改变时，只要XML Schema是不变的，那么Spring的配置就不会受到影响。

为了实现服务实现对具体装配者隐藏且自定义的xml配置最终必须转换成spring容器所需呀的bean，做出了一下的逻辑更改

（1）每一个元素节点对对应一个解释器（xml schema nameSpace命名空间），编写对应的解释器对自定义元素节点解析成spring所对应的beanDefinition，最终注册在spring容器中

（2）通过在编写定义自定义元素节点，预留拓展点接口，自定义如果需要拓展新的内容，只需要实现拓展点接口，添加相应的实现，便可以对原有组件进行拓展

4 Webx3启动

4.1 Webx应用启动入口

应用的web.xml类似于操作系统的引导程序。是一切Java Web应用的起点。简单来说，就是你写给Web容器的启动说明书。容器就按照你写的这份说明书来启动。web.xml定义于应用的初始化参数，在容器启动后统一存放在ServletContext中，作为应用的全局配置，后续spring容器启动主要依赖的也是该配置。

4.1.1 日志初始化

LogConfiguratorListener通过实现ServletContextListener接口监听应用启动ServletContextEvent事件，并从ServletContextEvent读取全局配置ServletContext读取日志相关的配置，进行日志系统的初始化

 <listener>
    <listener-class>com.alibaba.citrus.logconfig.LogConfiguratorListener</listener-class>
</listener>

日志系统初始化相关逻辑，主要就是读取相关的日志配置，通过默认的slf4j去查询相应的日志系统的配置文件（目前仅支持log4j和logback的日志系统初始化组件），如果ServletContext配置了日志参数就寻找相应的配置并使用该配置的参数初始化，否则使用默认的配置，如果依赖logback.jar就寻找WEB-INF下的logback.xml，如果依赖log4j的jar就寻找WEB-INF下的log4j.xml配置进行日志系统的初始化

public class LogConfiguratorListener implements ServletContextListener {

     public void contextInitialized(ServletContextEvent event) {
        ServletContext servletContext = event.getServletContext();

        // 取得所有以log开头的init params。
        Map<String, String> params = getLogInitParams(servletContext);

        // 从context init-param中取得logSystem的值，可能为null。
        String[] logSystems = getLogSystems(params);

        // 取得指定名称的logConfigurator，如未取得，则抛出异常，listener失败。
        logConfigurators = LogConfigurator.getConfigurators(logSystems);

        for (LogConfigurator logConfigurator : logConfigurators) {
            String logSystem = logConfigurator.getLogSystem();

            // 取得指定logConfigurator的配置文件。
            String logConfiguration = getLogConfiguration(params, logSystem);

            // 取得log配置文件。
            URL logConfigurationResource;

        try {
            logConfigurationResource = servletContext.getResource(logConfiguration);
        } catch (MalformedURLException e) {
            logConfigurationResource = null;
        }

        // 如未找到配置文件，则用默认的值来配置，否则配置之。
        if (logConfigurationResource == null) {
            servletContext
                    .log(String
                                 .format("Could not find %s configuration file \"%s\" in webapp context.  Using default configurations.",
                                         logSystem, logConfiguration));

            logConfigurator.configureDefault();
        } else {
            Map<String, String> props = logConfigurator.getDefaultProperties();
            initProperties(props);
            props.putAll(params);

            logConfigurator.configure(logConfigurationResource, props);
        }
    }
}
}

4.1.2 springExt容器初始化

这里是整个Webx应用的重要入口，WebxContextLoaderListener同样实现了ServletContextListener接口，监听应用的启动事件ServeltContextEvent，在此启动SpringExt容器，加载Webx环境

<listener>
    <listener-class>com.alibaba.citrus.webx.context.WebxContextLoaderListener</listener-class>
</listener>

打开WebxContextLoaderListener看一下源码，可以看到Webx3并没有重复造轮子，而是派生了Spring的容器监听类ContextLoaderListener，重写了createContextLoader方法，实现里面可以看到返回的WebxCoponenentsLoader类，并重写了该类的getDefaultContextClass，返回的类为springExt的容器类WebxComponentsContext，代替spring原有的默认的xmlApplicationContext容器类，前者完全兼容后者

public class WebxContextLoaderListener extends ContextLoaderListener {
@Override
protected final ContextLoader createContextLoader() {
    return new WebxComponentsLoader() {

        @Override
        protected Class<? extends WebxComponentsContext> getDefaultContextClass() {
            Class<? extends WebxComponentsContext> defaultContextClass = WebxContextLoaderListener.this
                    .getDefaultContextClass();

            if (defaultContextClass == null) {
                defaultContextClass = super.getDefaultContextClass();
            }

            return defaultContextClass;
        }
    };
}

protected Class<? extends WebxComponentsContext> getDefaultContextClass() {
    return null;
}
}

因为WebxContextLoaderListener派生了ContextLoaderListener，所以还是要从ContextLoaderListener分析Webx3的启动流程，看具体的实现逻辑创建了ContextLoader,因为WebxContextListener重写了createContextLoader,所以返回的结果是被重写了的WebxComponenetsContextLoader,并使用该类进行initWebApplicationContext初始化容器

public class ContextLoaderListener implements ServletContextListener {

    private ContextLoader contextLoader;

    /**
    * Initialize the root web application context.
    */
    public void contextInitialized(ServletContextEvent event) {
        this.contextLoader = createContextLoader();
        this.contextLoader.initWebApplicationContext(event.getServletContext());
    }
}

上面源码跟到了WebxComponentsLoader，并没有什么新发现，主要是继续调用Spring容器的ContextLoader类的initWebApplicationContext方法继续执行容器初始化流程

public class WebxComponentsLoader extends ContextLoader {

    @Override
    public WebApplicationContext initWebApplicationContext(ServletContext servletContext){
        this.servletContext = servletContext;
        init();
        return super.initWebApplicationContext(servletContext);
    }
}

在init方法中重要的一行代码如下，新建一个WebApplicationContext，由于之前WebxComponentsContext重写了getDefaultContextClass方法，所以此处拿到的容器类是WebxComponentsContext代替Spring原有的xmlApplicationContext容器类

this.context = createWebApplicationContext(servletContext);

继续跟代码可以看到容器启动的方法，整个容器的初始化过程，主要都是spring初始化的内容，不着重介绍，具体内容spring技术内幕里面介绍的比较完全

public void refresh() throws BeansException, IllegalStateException {
synchronized (this.startupShutdownMonitor) {
    // Prepare this context for refreshing.
    prepareRefresh();

    // Tell the subclass to refresh the internal bean factory.
    ConfigurableListableBeanFactory beanFactory = obtainFreshBeanFactory();

    // Prepare the bean factory for use in this context.
    prepareBeanFactory(beanFactory);
    try {
        // Allows post-processing of the bean factory in context subclasses.
        //被WebxComponentsContext所覆盖
        postProcessBeanFactory(beanFactory);

        // Invoke factory processors registered as beans in the context.
        invokeBeanFactoryPostProcessors(beanFactory);

        // Register bean processors that intercept bean creation.
        registerBeanPostProcessors(beanFactory);

        // Initialize message source for this context.
        initMessageSource();

        // Initialize event multicaster for this context.
        initApplicationEventMulticaster();

        // Initialize other special beans in specific context subclasses.
        onRefresh();

        // Check for listener beans and register them.
        registerListeners();

        // Instantiate all remaining (non-lazy-init) singletons.
        finishBeanFactoryInitialization(beanFactory);

        // Last step: publish corresponding event.
        //被WebxComponentsContext所覆盖
        finishRefresh();
    }
}
}

在上面可以看到被覆盖的方法postProcessBeanFactory，WebxComponentContext调用父类的其实是WebxComponentsLoader.postProcessBeanFactory的方法

public class WebxComponentContext extends WebxApplicationContext {
    @Override
    protected void postProcessBeanFactory(ConfigurableListableBeanFactory beanFactory) {
        super.postProcessBeanFactory(beanFactory);
        beanFactory.registerResolvableDependency(WebxComponent.class, component);
    }
}

WebxComponentsContext还覆盖了父类的一个方法如下，原有的spring容器指定了配置文件的位置为WEB-INF下的applicationCotext.xml，现在寻找的配置项为WEB-INF/webx.xml

public class WebxApplicationContext extends ResourceLoadingXmlWebApplicationContext {
    @Override
    protected String[] getDefaultConfigLocations() {
        if (getNamespace() != null) {
        return new String[] { WEBX_COMPONENT_CONFIGURATION_LOCATION_PATTERN.replace("*", getNamespace()) };
        } else {
            return new String[] { WEBX_CONFIGURATION_LOCATION };
        }
    }
}

WebxComponentsContext重写的第二个方法是finishRefresh（），优先执行spring主容器的创建，再执行各个子模块的容器初始化工作

@Override
protected void finishRefresh() {
    super.finishRefresh();
    getLoader().finishRefresh();
}

调用WebxComponentsLoader的finishRefresh对所有子容器进行初始化工作，父容器（WebxComponentsContext，通过webx.xml建立）若干子容器（即组件，WebxComponentContext，通过webx-*.xml建立），至此所有组件都初始化完成

public class WebxComponentsLoader extends ContextLoader {
    /**
    * 初始化所有components。
    */
    public void finishRefresh() {
        components.getWebxRootController().onFinishedProcessContext();

        for (WebxComponent component : components) {
            logInBothServletAndLoggingSystem("Initializing Spring sub WebApplicationContext: " + component.getName());

            WebxComponentContext wcc = (WebxComponentContext) component.getApplicationContext();
            WebxController controller = component.getWebxController();

            wcc.refresh();
         controller.onFinishedProcessContext();
    }

    logInBothServletAndLoggingSystem("WebxComponents: initialization completed");
    }
}

5 Webx3运行

5.1 Webx 请求入口

因为WebxFramework基于Servelt API，通过Filter可以拦截浏览器的所有请求，拦截到请求之后，便可以进入Webx3框架内部的执行链

<filter>
    <filter-name>webx</filter-name>
    <filter-class>com.alibaba.citrus.webx.servlet.WebxFrameworkFilter</filter-class>
</filter>

<filter-mapping>
    <filter-name>webx</filter-name>
    <url-pattern>/*</url-pattern>
</filter-mapping>

通过下面的类，我们便可以找到了所有请求的入口，进而得到应用的父容器，并将请求交给根容器的WebxRootController的Service方法处理

public class WebxFrameworkFilter extends FilterBean {
    protected void doFilter（）{
        getWebxComponents().getWebxRootController().service(request, response, chain);
    }
}

在WebxRootController中主要将request和response封装成requesContext，并将请求继续转发请求到handlerRequest()

public final void service(HttpServletRequest request, HttpServletResponse response, FilterChain chain){
RequestContext requestContext = null;

requestContext = assertNotNull(getRequestContext(request, response), "could not get requestContext");

if (isRequestPassedThru(request) || !handleRequest(requestContext)) {
    giveUpControl(requestContext, chain);
}

}

继续跟源码handlerRequest(),在此方法中首先根据请求查询相应的path，再根据path查找相应的组件容器，将请求转发给子容器的控制器，如果未指定的情况下，默认子容器的控制器为WebxController，请求由WebxRootController转发给WebxController

@Override
protected boolean handleRequest(RequestContext requestContext) throws Exception {
    HttpServletRequest request = requestContext.getRequest();

     String path = ServletUtil.getResourcePath(request);

    // 再根据path查找component
    WebxComponent component = getComponents().findMatchedComponent(path);
    boolean served = false;

    if (component != null) {
        try {
            WebxUtil.setCurrentComponent(request, component);
            served = component.getWebxController().service(requestContext);
        }finally {
            WebxUtil.setCurrentComponent(request, null);
        }
    }
    return served;
}

请求目前是转发到WebxContrller,在此主要是调用Pipeline实例执行整个流程的valve（类似于filter执行链，但是比filter功能更加强大，支持循环重复执行），整个框架的的约定优于配置都在此体现。一个请求进入，首先会进行url分析，得到相应的路径，检查csrfToken、权限的valve，再根据url的名字和后缀，分别执行不同的valve，最后进行模板渲染，返回Http请求结果。

public class WebxControllerImpl extends AbstractWebxController {
    private Pipeline pipeline;

    @Override
    public void onRefreshContext() throws BeansException {
        super.onRefreshContext();
        initPipeline();
    }

    private void initPipeline() {
        pipeline = getWebxConfiguration().getPipeline();
        log.debug("Using Pipeline: {}", pipeline);
    }

    public boolean service(RequestContext requestContext) throws Exception {
        PipelineInvocationHandle handle = pipeline.newInvocation();

        handle.invoke();    

        // 假如pipeline被中断，则视作请求未被处理。filter将转入chain中继续处理请求。
        return !handle.isBroken();
    }
}