获取spring容器上下文

方式一：
ApplicationContext context = new ClassPathXmlApplicationContext("applicationContext.xml");

applicationContext.xml 为配置文件

这种方式是从新加载了spring上下文， 很耗时间，一般在测试时偶尔使用。不推荐使用。
方式二：
写好的工具类如下：
/**
 * 获取spring上下文
 * 
 * @author fanbaodan
 *
 */
@Component
public class GetMySpringContext implements ApplicationContextAware {

	// 声明一个静态变量用于保存spring容器上下文
	@Autowired
	private static ApplicationContext context;

	@Override
	public void setApplicationContext(ApplicationContext applicationContext) throws BeansException {
		this.context = applicationContext;
	}

	public static ApplicationContext getMyApplicationContext() {
		return context;
	}
}

这种方式推荐使用，项目正常启动后，	注意@Autowired 将已经初始化好的spring上下文，注入到该类的静态属性中，也就是不用重新去加载。 推荐使用。

1、web.xml必须配置ContextLoaderListener监听器以及Spring容器上下文配置文件：

<context-param>
    <param-name>contextConfigLocation</param-name>
    <param-value>classpath:applicationContext.xml</param-value>
</context-param>
<listener>
    <listener-class>org.springframework.web.context.ContextLoaderListener</listener-class>
</listener>

2、Spring容器上下文配置文件至少需要context命名空间及基础包扫描：

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xmlns:context="http://www.springframework.org/schema/context"
       xsi:schemaLocation="
       http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-4.3.xsd
       http://www.springframework.org/schema/context http://www.springframework.org/schema/context/spring-context-4.3.xsd">

    <context:component-scan base-package="com"/>

</beans>

3、获取Spring容器上下文：

1)直接注入：

@Autowired
private ApplicationContext ac;

2）Spring容器上下文需要通过ServletContext获取，所以需要先获取到ServletContext：

public void getApplicationContext(HttpSession session) {
        ServletContext context = session.getServletContext();
        ApplicationContext ac = (ApplicationContext) context.getAttribute(WebApplicationContext.ROOT_WEB_APPLICATION_CONTEXT_ATTRIBUTE);
        DemoController controller = ac.getBean("demoController", DemoController.class);
        System.out.println(controller);
    }

3）使用WebApplicationContextUtils获取：

public void getApplicationContext(HttpSession session) {
        ServletContext context = session.getServletContext();
        ApplicationContext ac = WebApplicationContextUtils.getWebApplicationContext(context);
        DemoController controller = ac.getBean("demoController", DemoController.class);
        System.out.println(controller);
    }

4）通过ApplicationContextAware接口获取：

1.编写类实现ApplicationContextAware接口并交给spring管理：

@Component
public class ApplicationContextProvider implements ApplicationContextAware {
    private ApplicationContext applicationContext;

    public void setApplicationContext(ApplicationContext applicationContext) throws BeansException {
        this.applicationContext = applicationContext;
    }

    public ApplicationContext getApplicationContext() {
        return applicationContext;
    }
}

2.在需要上下文的类中注入这个类，获取spring容器上下文：

@Autowired
private ApplicationContextProvider applicationContextProvider;

@RequestMapping("/getApplicationContext")
public void getApplicationContext(HttpSession session) {
    ApplicationContext ac = applicationContextProvider.getApplicationContext();
    DemoController controller = ac.getBean("demoController", DemoController.class);
    System.out.println(controller);
}

5）Springboot项目获取Spring容器上下文：

@SpringBootApplication
public class SpringbootDemoApplication {

    private static ApplicationContext ac;

    public static void main(String[] args) {
       ac = SpringApplication.run(SpringbootDemoApplication.class, args);
    }

    @Bean
    public ApplicationContext getApplicationContext() {
        return ac;
    }

}

4：ClassPathXmlApplicationContext、WebApplicationContext、ApplicationContext关系：

Kubernetes容器上下文环境

　　下面我们将主要介绍运行在Kubernetes集群中的容器所能够感知到的上下文环境，以及容器是如何获知这些信息的。

　　首先，Kubernetes提供了一个能够让容器感知到集群中正在发生的事情的方法：环境变量。作为容器环境组成的一部分，这些集群信息对于容器构建“集群环境感知”起着非常重要的作用。其次，Kubernetes容器环境还包括一系列与容器生命周期相关的容器钩子，其对应的回调函数hook handler可以作为单个容器可选定义项的一部分。这个容器钩子与操作系统传统进程模型的通知回调机制有些类似。其实，还有一个与容器环境相关的重要部分是容器可用的文件系统。通过前面的讨论可知，在Kubernetes中，容器的文件系统由一个容器镜像和若干个Volume组成。

　　下面我们将着重讨论暴露给容器的集群信息和用于向容器发布对其生命周期管理信息的容器钩子这两种同容器上下文环境协作的方法。

1、集群环境感知

　　运行在Kubernetes集群中的一个容器在容器内部能够感知两种类型的环境变量信息，一种是与容器自身相关的信息，另一种是集群的信息。

1.1容器自身信息

　　容器能够感知到的与容器自身相关的信息包括运行该容器的pod的名字、pod所在的namespace、在pod资源配置文件中env字段定义的键/值对，等等。其中，pod的名字被设置成容器的的主机名，而且可以在容器内通过所有访问主机名的方式获得，例如，hostname命令或JAVA中InetAddress.getLocalHost()函数调用。pod的名字和namespace还可以通过downwardAPI进行访问。对容器而言，用户在pod资源配置文件中自定义的环境变量的可访问性与在Docker镜像中指定的环境变量是一样的。downwardAPI示例如下：



[root@k8s-master downwardapi]# cat test-downwardapi.yaml 
apiVersion: v1
kind: Pod
metadata:
  name: test-downwardaoi-volume
  labels:
    name: test-downwardaoi-volume
    zone: us-east
    cluster: test-cluster1
  annotations:
    build: two
    builder: zhenyuyaodidiao
spec:
  containers:
    - name: test-hostpath
      image: registry:5000/back_demon:1.0
      volumeMounts:
       - name: podinfo
         mountPath: /home/laizy/podinfo
         readOnly: false
      command:
      - /run.sh
  volumes:
  - name: podinfo
    downwardAPI:
      items:
       - path: "pod_name"
         fieldRef:
           fieldPath: metadata.name
       - path: "pod_namespace"
         fieldRef:
           fieldPath: metadata.namespace
       - path: "pod_labels"
         fieldRef:
           fieldPath: metadata.labels
       - path: "pod_annotations"
         fieldRef:
           fieldPath: metadata.annotations

[root@k8s-master downwardapi]# kubectl create -f test-downwardapi.yaml 
pod "test-downwardaoi-volume" created

[root@k8s-master downwardapi]# kubectl exec -ti test-downwardaoi-volume /bin/bash
[root@test-downwardaoi-volume /]# cd /home/laizy/podinfo/
[root@test-downwardaoi-volume podinfo]# ls
pod_annotations  pod_labels  pod_name  pod_namespace
[root@test-downwardaoi-volume podinfo]# cat pod_annotations 
build="two"
builder="zhenyuyaodidiao"
kubernetes.io/config.seen="2017-03-22T09:42:11.832955302+08:00"
kubernetes.io/config.source="api"
[root@test-downwardaoi-volume podinfo]# cat pod_labels 
cluster="test-cluster1"
name="test-downwardaoi-volume"
zone="us-east"
[root@test-downwardaoi-volume podinfo]# cat pod_name
test-downwardaoi-volume
[root@test-downwardaoi-volume podinfo]# cat pod_name
test-downwardaoi-volume
[root@test-downwardaoi-volume podinfo]# cat pod_namespace 
default
[root@test-downwardaoi-volume podinfo]# exit
exit



 

1.2集群信息

　　我们在前面已经讨论过Kubernetes服务发现的两种机制：DNS和环境变量。service环境变量属于集群信息，在容器创建时由Kubemetes集群API注人，在容器内以环境变量或域名的方式被访问。

2．容器钩子

　　容器钩子是Kubemetes针对容器生命周期管理引入的事件处理机制，它负责监听Kubemetes对容器生命周期的管理信息，并将这些信息以广播的形式通知给容器。然后执行相应的回调函数。

2.1容器钩子类型

　　Kubemetes支持两种类型的容器钩子，分别为PostStart和PreStop。

　　PostStart。该钩子在容器被创建后立刻触发，通知容器它已经被创建。该钩子不需要向其所对应的hook handler传人任何参数。如果该钩子对应的hook handler执行失败，则该容器会被杀死，并根据该容器的重启策略决定是否要重启该容器。

　　PreStop。该钩子在容器被删除前触发，其所对应的hook handler必须在删除该容器的请求发送给Docker daemon之前完成。在该钩子对应的hook handler完成后不论执行的结果如何，Docker daemon会发送一个SGTERN信号量给Docker daemon来删除该容器。同样地。该钩子也不需要传人任何参数

2.2hook handler执行

　　当一个容器管理hook发生时，管理系统将会在容器中调用注册的hook handler。其中hook handler通过在包含该容器的pod资源配置文件的Lifecycle字段中定义来完成注册。注意，当hook handler在执行时，其他对该容器所在pod的管理动作将被阻塞除非该容器异常退出。而如果你自定义的hook handler阻塞时，其他对pod的管理操作包括容器健康检查将不会发生，直到hook handler继续执行完毕。因此，一般建议用户自定义的hook handler代码尽可能地轻量化，尽管确实有一些场景的hook handler需要长时间运行（例如在容器时退出保存运行状态等）。

2.3hook handler的执行方式

　　hook handler是hook在容器内执行的回调函数，也即hook暴露给容器的方式。Kubemetes支持两种不同的hook handler类型，分别是Exec和HTTPGet。

　　　　Exec。在容器的cgroup和namespace内启动一个新进程来执行指定的命令，由该命令消耗的资源全部要计人容器的消耗。正如在之前容器健康检查中提到的，如果Exec执行的命令最后在标准输出stdout的结果为0k，就代表handler执行成功，否则就被认为执行异常，并且Kuberlet将强制重新启动该容器。

　　　　HTTPGet。向容器的指定接口发起一个HTTP请求作为handler的具体执行内容，并通过返回的HTTP状态码来判断该请求执行是否成功。

　　综上，hook机制为用户提供了一种能够根据容器生命周期及其上下文的变化来触发不同操作的协作方法。这对于很多需要精细控制容器的场景是非常有用的，比如在容器结束前执行一些清理工作来保证其“优雅”退出。以下给出hook执行exec的示例：



[root@k8s-master hook]# cat test-lifecycle-hostpath.yaml 
apiVersion: v1
kind: Pod
metadata:
  labels:
    name: test-lifecycle-hostpath
    role: master
  name: test-lifecycle-hostpath
spec:
  containers:
    - name: test-lifecycle-hostpath
      image: registry:5000/back_demon:1.0
      lifecycle:
        postStart:
          exec:
            command:
              - "touch"
              - "/home/laizy/test/hostpath/post-start"
        preStop:
          exec:
            command:
              - "touch"
              - "/home/laizy/test/hostpath/pre-stop"
      volumeMounts:
       - name: testhost
         mountPath: /home/laizy/test/hostpath
         readOnly: false
      command:
      - /run.sh
  volumes:
  - name: testhost
    hostPath:
     path: /home/testhost
[root@k8s-master hook]# date
2017年 03月 22日 星期三 10:21:58 CST
[root@k8s-master hook]# kubectl create -f test-lifecycle-hostpath.yaml 
pod "test-lifecycle-hostpath" created
[root@k8s-master hook]# kubectl get pod -o wide
NAME                                READY     STATUS    RESTARTS   AGE       IP          NODE
test-lifecycle-hostpath             1/1       Running   0          13s       10.0.9.3    k8s-node-3
[root@k8s-master hook]# date
2017年 03月 22日 星期三 10:22:52 CST
[root@k8s-master hook]# kubectl delete pod test-lifecycle-hostpath 
pod "test-lifecycle-hostpath" deleted



在node3上查看外挂出来的路径上，生成了两个文件，post-start文件是在pod创建之后生成的；pre-stop文件是在pod删除之前生成的。

[root@k8s-node-3 ~]# ll /home/testhost/
总用量 0
-rw-r--r--. 1 root root 0 3月  22 10:22 post-start
-rw-r--r--. 1 root root 0 3月  22 10:23 pre-stop
[root@k8s-node-3 ~]# 

 

对应的httpGet示例简单示意如下：



containers:
  - name: lifecycle
    image: busybox
    lifecycle:
      postStart:
        exec:
          command:
            - "touch"
            - "/var/log/lifecycle/post-start"
      preStop:
        httpGet:
          path: "/abort"
          port: 8080



 

kubernetes 容器内获取Pod信息(包括：宿主主机IP)

https://blog.csdn.net/kozazyh/article/details/79463688

kubernetes 自从1.7开始，可以在pod 的container 内获取pod的spec,metadata 等信息。

具体方法可以通过env获取：

      env:
        - name: MY_NODE_NAME
          valueFrom:
            fieldRef:
              fieldPath: spec.nodeName
        - name: MY_POD_NAME
          valueFrom:
            fieldRef:
              fieldPath: metadata.name
        - name: MY_POD_NAMESPACE
          valueFrom:
            fieldRef:
              fieldPath: metadata.namespace
        - name: MY_POD_IP
          valueFrom:
            fieldRef:
              fieldPath: status.podIP
        - name: MY_POD_SERVICE_ACCOUNT
          valueFrom:
            fieldRef:
              fieldPath: spec.serviceAccountName

spec.nodeName ： pod所在节点的IP、宿主主机IP

status.podIP ：pod IP

metadata.namespace : pod 所在的namespace

更多参数：https://kubernetes.io/docs/tasks/inject-data-application/environment-variable-expose-pod-information/

https://github.com/kubernetes/kubernetes/issues/24657

 

kubernetes 通过环境变量暴露POD的信息给容器

https://blog.csdn.net/qq_21816375/article/details/80232109

有时候，容器需要获取pod的信息时，就可以通过设置环境保护来实现 

例子 

1.使用POD 的字段的值作为环境变量的值

apiVersion: v1
kind: Pod
metadata:
  name: dapi-envars-fieldref
spec:
  containers:
    - name: test-container
      image: k8s.gcr.io/busybox
      command: [ "sh", "-c"]
      args:
      - while true; do
          echo -en '\n';
          printenv MY_NODE_NAME MY_POD_NAME MY_POD_NAMESPACE;//对应下面的环境变量的值
          printenv MY_POD_IP MY_POD_SERVICE_ACCOUNT;
          sleep 10;
        done;
      env:
        - name: MY_NODE_NAME
          valueFrom:
            fieldRef:
              fieldPath: spec.nodeName
        - name: MY_POD_NAME
          valueFrom:
            fieldRef:
              fieldPath: metadata.name
        - name: MY_POD_NAMESPACE
          valueFrom:
            fieldRef:
              fieldPath: metadata.namespace
        - name: MY_POD_IP
          valueFrom:
            fieldRef:
              fieldPath: status.podIP
        - name: MY_POD_SERVICE_ACCOUNT
          valueFrom:
            fieldRef:
              fieldPath: spec.serviceAccountName
  restartPolicy: Never

2.使用容器的字段的值作为环境变量的值 

例子

apiVersion: v1
kind: Pod
metadata:
  name: dapi-envars-resourcefieldref
spec:
  containers:
    - name: test-container
      image: k8s.gcr.io/busybox:1.24
      command: [ "sh", "-c"]
      args:
      - while true; do
          echo -en '\n';
          printenv MY_CPU_REQUEST MY_CPU_LIMIT;
          printenv MY_MEM_REQUEST MY_MEM_LIMIT;
          sleep 10;
        done;
      resources:
        requests:
          memory: "32Mi"
          cpu: "125m"
        limits:
          memory: "64Mi"
          cpu: "250m"
      env:
        - name: MY_CPU_REQUEST
          valueFrom:
            resourceFieldRef:
              containerName: test-container
              resource: requests.cpu
        - name: MY_CPU_LIMIT
          valueFrom:
            resourceFieldRef:
              containerName: test-container
              resource: limits.cpu
        - name: MY_MEM_REQUEST
          valueFrom:
            resourceFieldRef:
              containerName: test-container
              resource: requests.memory
        - name: MY_MEM_LIMIT
          valueFrom:
            resourceFieldRef:
              containerName: test-container
              resource: limits.memory
  restartPolicy: Never

参考： 
environment-variable-expose-pod-information

Kubernetes 配置Pod和容器(十五) 通过环境变量公开Pod信息到容器

https://www.jianshu.com/p/577deb21ba1d

这个章节展示了如何使用环境变量公开pod的信息到它自己运行的容器里面。环境变量可以公开Pod字段和容器字段。

有两种方式用来公开Pod和容器字段给运行的容器：环境变量和DownwardAPIVolumeFiles。

使用Pod字段作为环境变量的值

在本次实验，创建包含一个容器的Pod。下面是这个Pod的配置文件：

apiVersion: v1
kind: Pod
metadata:
  name: dapi-envars-fieldref
spec:
  containers:
    - name: test-container
      image: gcr.io/google_containers/busybox
      command: [ "sh", "-c"]
      args:
      - while true; do
          echo -en '\n';
          printenv MY_NODE_NAME MY_POD_NAME MY_POD_NAMESPACE;
          printenv MY_POD_IP MY_POD_SERVICE_ACCOUNT;
          sleep 10;
        done;
      env:
        - name: MY_NODE_NAME
          valueFrom:
            fieldRef:
              fieldPath: spec.nodeName
        - name: MY_POD_NAME
          valueFrom:
            fieldRef:
              fieldPath: metadata.name
        - name: MY_POD_NAMESPACE
          valueFrom:
            fieldRef:
              fieldPath: metadata.namespace
        - name: MY_POD_IP
          valueFrom:
            fieldRef:
              fieldPath: status.podIP
        - name: MY_POD_SERVICE_ACCOUNT
          valueFrom:
            fieldRef:
              fieldPath: spec.serviceAccountName
  restartPolicy: Never


在这个配置文件，可以看到五个环境变量。env字段是个数组。数组里面的第一个元素指定了MY_NODE_NAME环境变量，它的值是从Pod的spec.nodeName里面获取的。类似的其他的环境变量获取pod的字段名称。

注意：这些例子里面的字段是pod的字段。不是运行在pod里面的容器的字段。

创建pod：

kubectl create -f test.yaml


验证运行在pod里面的容器：

kubectl get pods


查看容器的日志：

kubectl logs dapi-envars-fieldref


输出展示了选择的环境变量的值：

minikube
dapi-envars-fieldref
default
172.17.0.4
default


为何在日志里面是这些值，可以看配置文件的command和args。当容器启动的时候，把这个五个环境变量的值写入的标准输出里面。每十秒钟重复一次。

下一步，通过shell进入Pod运行的容器里面：

kubectl exec -it dapi-envars-fieldref -- sh


在shell里面，查看环境变量：

/# printenv


输出展示了确定已经把pod字段的值分配给环境变量：

MY_POD_SERVICE_ACCOUNT=default
...
MY_POD_NAMESPACE=default
MY_POD_IP=172.17.0.4
...
MY_NODE_NAME=minikube
...
MY_POD_NAME=dapi-envars-fieldref


使用容器字段作为环境变量的值

在上面的实验，使用pod字段作为环境变量的值。在下一个实验，可以使用容器字段作为环境变量的值。下面是Pod的配置文件：

apiVersion: v1
kind: Pod
metadata:
  name: dapi-envars-resourcefieldref
spec:
  containers:
    - name: test-container
      image: gcr.io/google_containers/busybox:1.24
      command: [ "sh", "-c"]
      args:
      - while true; do
          echo -en '\n';
          printenv MY_CPU_REQUEST MY_CPU_LIMIT;
          printenv MY_MEM_REQUEST MY_MEM_LIMIT;
          sleep 10;
        done;
      resources:
        requests:
          memory: "32Mi"
          cpu: "125m"
        limits:
          memory: "64Mi"
          cpu: "250m"
      env:
        - name: MY_CPU_REQUEST
          valueFrom:
            resourceFieldRef:
              containerName: test-container
              resource: requests.cpu
        - name: MY_CPU_LIMIT
          valueFrom:
            resourceFieldRef:
              containerName: test-container
              resource: limits.cpu
        - name: MY_MEM_REQUEST
          valueFrom:
            resourceFieldRef:
              containerName: test-container
              resource: requests.memory
        - name: MY_MEM_LIMIT
          valueFrom:
            resourceFieldRef:
              containerName: test-container
              resource: limits.memory
  restartPolicy: Never


在配置文件里面，可以看到四个环境变量。env字段是一个数组。数组的第一个元素指定了MY_CPU_REQUEST环境变量的值通过名字为test-container容器的request.cpu字段获取。类似的其他的环境变量通过他们对应的容器字段获取相应的值。

创建Pod：

kubectl create -f test.yaml


验证Pod里面的容器已经运行：

kubectl get pods


查看容器日志：

kubectl logs dapi-envars-resourcefieldref


输出展示了选择的环境变量的值：

1
1
33554432
67108864

目录,更新ing,学习Java的点滴记录
  目录放在这里太长了,附目录链接大家可以自由选择查看--------Java学习目录
SpringMvc知识
第一篇---->SpringMvc初识|MVC|三层架构

第二篇---->IoC容器上下文和映射请求上下文

第三篇---->熟悉基本开发流程

第四篇---->接收各类请求参数的方式

第五篇---->获取请求中的Request,Session,Cookie等对象属性

第六篇---->拦截器开发

第七篇---->视图和视图解析器

第八篇---->数据校验

第九篇---->文件上传方式

第十篇---->数据转换和数据格式化
1 引入

看过第一篇的小伙伴不知是否还记得web.xml中配置的内容呢?重新贴一下配置内容回顾一下

  
当时入门案例里面用不到SpringIOC容器,所以SpringIOC容器的初始化时被注释掉的,打开注释也没关系,只需要在/WEB-INF目录下新建一个applicationContext.xml即可
现在我们来针对这个文件的内容进行细致的研究一下,这里面配置了DispatcherServlet和ContextLoaderListener,那么它们是如何初始化SpringIOC容器上下文和映射请求上下文的呢?PS:映射请求上下文是基于SpringIOC上下文扩展出来的.

2 初始化Spring IOC上下文

JavaWeb容器在其生命周期中提供ServletContextListener接口,这个接口可以在Web容器初始化和结束期中执行一定的逻辑,换句话说,通过它可以使得在DispatcherServlet初始化前就可以完成SpringIOC容器的初始化,也可以在结束期完成对SpringIOC容器的销毁,只要实现了ServletContextListener接口的方法就可以.SpringMvc交给了类ContextLoaderListener,现在我们看一下它的源码

  
从源码中可以看到ContextLoaderListener实现了ServletContextListener接口,并且在类中提供了初始化和销毁的方法,这样就可以明白在web.xml中配置ContextLoaderListener的作用了,可以在JavaWeb应用中初始化SpringIOC容器,并将其销毁.这样就可以让SpringIOC容器去管理整个Web工程的资源了.

3 初始化映射请求上下文

映射请求上下文是通过DispatcherServlet初始化的,它和普通的Servlet也是一样的,可以根据自己的需要配置它初始化的时间点,比如是在应用启动时就初始化还是等待用户第一次请求时进行初始化.
上面提到过SpringIOC容器的初始化需要借助与ContextLoaderListener,但是即便即没有注册ContextLoaderListener,DispatcherServlet也会在其初始化的时候对SpringIOC容器进行初始化.但是这种方式不是最好的选择,下面会详谈,那么该怎么选择初始化DispatcherServlet的时刻呢?
首先,初始化一个SpringIOC容器是一个耗时的操作,所以这个工作不应该放到用户请求上,没必要让一个用户陷入长期的等待中,因此大部分场景下,都应该让DispatcherServlet在服务器启动期间就完成SpringIOC容器的初始化,可以选择在web容器刚启动的时候或者在web容器载入DispatcherServlet的时候进行初始化.最好的时间点是--web容器刚开始的时候对SpringIOC进行初始化,因为在整个web的初始化中,不只是DispatcherServlet需要使用到SpringIOC的资源,其他的组件可能也需要.在最开始就初始化可以让web中的各个组件共享资源.因此大部分情况下都建议使用ContextLoaderListener进行初始化.
下面看一下DispatcherServlet的设计类结构图

  
从结构图中可以看出,DispatcherServlet的父类是FrameworkServlet,而FrameworkServlet的父类则是HttpServletBean.HttpServletBean继承了Web容器所提供的HttpServlet,所以DispatcherServlet是一个可以载入Web容器中的Servet.
Web容器对于Servlet的初始化,首先是调用其init方法,对于DispatcherServlet也是如此,DispatcherServlet的初始化方法在其父类HttpServletBean中

  
在类HttpServletBean中的init方法中可以看到ininServletBean()方法,这个方法是交给子类去实现的,现在我们去HttpServletBean的子类FrameworkServlet中看看initServletBean方法

  
从上图中就可以清楚看到SpringIOC容器的初始化过程了.当IoC容器没有对应的初始化的时候,DispatcherServlet就会尝试去创建它,最后调度onRefresh方法,该方法也是DispatcherServlet中一个非常重要的方法,因为它`将初始化SpringMvc的各个组件,而onRefresh方法就在DispatcherServlet,我们马上看看它

  
这些组件很复杂,但确实SpringMvc的核心组件,了解一下基本内容

  1) MultipartResolver:文件解析器,用于支持服务器的文件上传

  2) LocaleResolver:国际化解析器,可以提供国际化的功能

  3) ThemeResolver:主题解析器,类似于软件皮肤的转换功能

  4) HandlerMappings:SpringMvc中非常重要的内容,它包装开发者提供的一个控制器方法和它的拦截器,通过调用它就能够运行控制器

  5) HandlerAdapter:处理器适配器,因为处理器会在不同的上下文中运行,所以SpringMVC会先找到合适的适配器,然后运行处理器服务方法.

  6)HandlerExceptionResolver:处理器异常解析器,处理器可能产生异常,如果产生异常,则可以通过异常解析器来处理它.

  7) RequestToViewNameTranslator:视图逻辑名称转换器,在控制器中返回一个视图的名称,通过它可以找到实际的视图.当处理器没有返回逻辑视图名等相关信息时,自动将请求URL映射为逻辑视图名.

  8) ViewResolver:视图解析器,当控制器返回后,通过视图解析器会把逻辑视图名进行解析,然后定位实际视图.
由此可见,启动期间DispatcherServlet会加载这些配置的组件进行初始化,这就是我们为什么并不需要很多配置就能够使用SpringMvc的原因了