你的位置:首页 > Java教程

[Java教程]jetty加载spring


带着疑问开始

web.

先拿一个最简单的spring mvc web.

启动报错?还是加载未知结果?还是毫无影响?

结果是什么呢?让我们用实践来证明一下:go->jetty-spring-context project 现场演示

//todo 之后贴出结果

applicationContext.

最简单的配置(这样不仅产生两个容器而且每个容器都生成一样的bean)

applicationContext:

spring-mvc-servlet.

正确的配置其中之一

 1 applicationContext. 2 <? 3 <beans  4     5     6    xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-4.1.xsd 7    http://www.springframework.org/schema/context http://www.springframework.org/schema/context/spring-context-4.1.xsd"> 8   <!--正确的配置--> 9   <context:component-scan base-package="com.meituan.jetty.spring">10     <context:exclude-filter type="annotation" expression="org.springframework.stereotype.Controller"/>11   </context:component-scan>12 </beans>13 14 spring-mvc-servlet.15 <beans 16    17    18    xsi:schemaLocation="http://www.springframework.org/schema/beans19     http://www.springframework.org/schema/beans/spring-beans.xsd20     http://www.springframework.org/schema/context http://www.springframework.org/schema/context/spring-context.xsd">21   <!--正确的配置-->22   <context:component-scan base-package="com.meituan.jetty.spring.controller"/>23   <bean class="org.springframework.web.servlet.view.InternalResourceViewResolver">24     <property name="prefix" value="/"/>25     <property name="suffix" value=".jsp"/>26   </bean>27 </beans>

可以么?go->jetty-spring-context project 现场演示问题来了,通过结果我们发现,确实有两个容器,那么由于两个容器同时可以有一样的beans,那是否可以直接去掉ApplicationContext容器呢?

applicationContext.

结果:applicationContext.

两个context容器到底是怎样的

  1. 两个容器分别是怎么初始化的呢?
  2. 为什么applicationContext容器就是mvc context容器的父容器呢?
  3. 这两个容器分别是什么类型的applicationContext实现呢?(我们知道applicationContext是接口)

下边的图是applicationContext接口的少部分实现

深入源码解决疑难

为什么不管怎么配置app.

下边让我们用源码一步一步来分析其中的奥妙

启动jetty容器入口

 ......................前边还有一大段代码

初始化调用的是mms server的start方法,其实server没有start方法,是它的父类AbstractLifeCyle的start方法,然后再回调,我们来看下server的结构

在继续讲server是怎么一步步调用之前,我们需要知道两个事情

  1. ContextLoaderListener

  2. DispatcherServlet

ContextLoaderListener和DispatcherServlet的实质(插播)

contextLoaderListerner实质是实现了EventListener的一个事件监听器

相关事件通知,在我的另外一篇wiki中有详细介绍:

事件通知机制深入源码#事件通知机制深入源码-ApplicationListener

或者 直接看这里:Spring事件通知机制详解

contextLoaderListerner 的方法  contextInitialized  会被回调

DispatcherServlet实质上是一个servlet,当然,这个不用说也看的很清楚

DispatcherServlet 的父类FrameworkServlet的方法initServletBean会被回调

(警告)   这时候我们还要知道一个事情:contextLoaderListerner 和 DispatcherServlet 是在spring的两个package里边,前者在spring-web里边,后者在spring-webmvc里边,这个对后边的理解有帮助

启动jetty容器入口(续)

为什么listener能够无论以哪种姿态都会优先于servlet执行呢?

要解决这个问题,我们先看下listener是在何时被回调的:

首先大概浏览下这个图,这里对WebAppContext和ContextHandler大概有一个映像(当然,这个是jetty的源码)

jetty启动,会初始化一个WebAppContext(WebAppContext 继承了 ServletContextHandler ,ServletContextHandler  继承了ContextHandler ,而且他们都实现了 )对象;

最终,WebAppContext对象的startContext()方法会被实现,如下图调用链:

而startContext方法又做了什么事情呢?带着疑问,我们走进下边的代码:

我们发现,ContextHandler里边存了一个listener的集合,而恰巧我们的 ContextLoaderListener 实例也在这个集合当中;

我们看到这里把ContextLoaderListener和event事件传递给了callContextInitialized方法,所以ContextLoaderListener的contextInitialized方法最终会被调用,

到此为止,我们就解释了ContextLoaderListener是会被合理的初始化的;

至于ContextLoaderListener初始化的详细过程,请看这里:浅谈jetty如何初始化spring容器-ContextLoaderListener初始化context容器的过程

咦?好像有什么不对的地方。哦,对,本来是WebAppContext的startContext方法,怎么会跑到ContextHandler的startContext方法,看上图,

是子类父类的关系,原来如此;

看调用链,再来说说 boot 本来调用server的start,为什么会走到lifeCycle呢?

原来 server 继承了 AbstractLifeCycle,jetty源代码里边大量运用了 模板方法和类模板方法,我们开发的时候也可以学习这种设计模式,减少重复代码,提高代码复用率。

讲了这么多,还没讲到 为什么 listener 总是在 servlet之前执行呢?

莫急,且听下边讲解

如下,WebAppContext的 doStart 方法被调用,此时WebAppContext自己实现了一部分,其余直接调用父类->ContextHandler的doStart方法

(咦,不对,父类不是ServletContextHandler么;哦,ServletContextHandler并未重写这个方法)

接下来调用ContextHandler的doStart方法

ContextHandler再次调用子类WebAppContext的方法 startContext()

WebAppContext 首先调用 startWebApp,然后 startWebApp 再次调用父类 ServletContextHandler的 startContext方法

这里就比较有意思了:ServletContextHandler首先调用父类,也就是ContextHandler的startContext方法,还记得父类的这个方法发生了什么吗?

对!父类这个方法里边初始化了 ContextLoadListener ,也就是初始化了所有的 事件通知 !!!

事件通知完成之后,开始调用servlet的initialize方法,初始化servlet;servlet初始化详解:深入浅出jetty初始化spring容器-DispatcherServlet初始化context容器的过程

(信息)  也就是说:frameworkServlet初始化方法的回调是由ServletContextHandler的startContext方法引起的!!!

看下边 listener和servlet的执行顺序:

至此为止,我们剖析了 jetty初始化 为什么 listener的执行一定会先于servlet!!!(眨眼)(眨眼)(眨眼)

ContextLoaderListener初始化context容器的过程

ContextLoaderListener结构

ContextLoaderListener入口

首先,回调ContextLoaderListener的contextInitialized方法

然后调用父类ContextLoader的contextInitialized方法,第一次初始化的时候 org.springframework.web.context.WebApplicationContext.ROOT == null

紧接着在1的时候创建context

我们看看 context 到底是怎么创建的?创建的是哪种类型?红框决定了创建哪种类型的 applicationContext

如下图,通过strategy决定创建哪种类型

strategy又是怎么初始化的呢?

look

可见,是这个配置文件决定了,wepApplicationContext的类型是

最终调用 AbstractApplicationContext的refresh方法,根据配置文件内容,开始初始化;

AbstractApplicationContext的refresh的初始化都知道吧?不知道的话,可以看我这篇关于spring初始化顺序的文章:Spring Init&Destroy#spring容器的主要入口

DispatcherServlet初始化context容器的过程

DispatcherServlet结构

DispatcherServlet入口

初始化webApplicationContext,

创建webApplicationContext

这里的contextClass是这么决定的

最终也是调用refresh实例化的

最终完成第二个容器的初始化