m0_37298252的博客

扫描的代码基本上就是Feign的源码，略微修改，扫描的路径是自定义的，而不是从根路径扫，因为我们自己的项目，Feign接口是在指定位置的，然后扫描到的BeanDefinition，转化为类名，这样就得到了所有@FeignClient标注的类名列表。看到这里，便已经有了大致思路了，这里的InstanceSupplier，持有了从@FeignClinent中解析到的各种属性，并在将来实例化的时候，将这些属性处理为FeignClient的请求路径。

上篇文章介绍完SpringBoot内置tomcat的启动流程后，SpringBoot在Spring容器启动流程中做的扩展就大体介绍完了，本节继续SpringBoot的run方法，介绍一个比较有用的扩展点：ApplicationRunner当然，在内置tomcat启动完成，到这行callRunners被调用，中间还经历了一些事件的发布，比如ApplicationStartedEvent，我们之前已经介绍过事件发布的原理，并详细分析了好几个事件了，它们发布的流程都是一致的，相信看到这里的朋友，已经很熟悉Spr

SpringBoot最初开始流行的时候，一个很重要的区别就是，我们不需要单独配置tomcat了，在传统的SSM项目中，我们要为项目指定tomcat目录，开发完上线的时候，要把项目打成一个war包，部署到tomcat中，而SpringBoot已经默认为我们的web项目内置了一个tomcat。initThemeSource主要是初始化了web项目的UI主题，它检查了容器中是否存在名为themeSource的Bean，如果不存在的话，就初始化一个ResourceBundleThemeSource。...

前几篇文章聊完了prepareContext方法，本文继续SpringApplication#run方法的下一行：refreshContext这是Spring容器启动过程最重要的一个步骤，所有的扫描、解析、注入等等都在这里面完成的，当然本文依然是把焦点聚集在SpringBoot上，它的自动配置，也是在容器refresh的过程中执行的作为SpringBoot项目，启动类会加一个注解@SpringBootApplication，我们从这个注解开始入手，看它都做了哪些初始化，怎么整合到容器的启动流程并完成自

本文分析SpringBoot启动过程中的ApplicationPreparedEvent事件，它跟上文的事件ApplicationContextInitializedEvent一样，都是在prepareContext方法中发布的，同样算是对该方法的补充，正常情况下，接收到该事件的监听器一共有四个

这篇也是对prepareContext方法的补充，在执行完内置的ApplicationContextInitializer后，该方法发布了一个事件ApplicationContextInitializedEvent，在默认情况下，接收到事件的监听器有两个

本篇文章是对上篇prepareContext的补充，在该方法的执行过程中，遍历了最初从META-INF/spring.factories文件中加载到的ApplicationContextInitializer，依次调用了其initialize方法回顾第一篇文章，SpringApplication初始化的时候，一共加载到了6个内置的ApplicationContextInitializer，本篇文章就逐一分析每个内置的初始化器做了哪些事情```javaorg.springframework.boot.

本文继续SpringApplication的run方法往下分析，看prepareContext这行代码先看下几个入参，context是刚新建的容器，environment是已经完成了配置文件装在等一系列加工的环境对象，listeners中有一个事件发布器，内部含有springboot内置的监听器列表，applicationArguements是对命令行参数的一个封装，printerBanner是上面打印过的启动banner进入方法实现 private void prepareContext(C

容器创建完成后，继续本文介绍SpringBootExceptionReporter，它是SpringBoot项目启动过程的异常的分析器public ConfigurableApplicationContext run(String... args) { ...... ...... try { ...... ...... exceptionReporters = this.getSpringFactoriesInstances(SpringBootExceptionReporter.cl

Spring容器创建的过程，本文并不准备详细介绍，因为本系博文的主题是分析SpringBoot源码，重点放在SpringBoot基于Spring所做的扩展这个系列最初的目标，是把SpringBoot的源码一行一行地掰扯清楚，我也尽力在按这个标准来写，但要说把Spring源码也逐行分析清楚，我还不敢夸下这个海口，而且就我目前掌握的皮毛，感觉没有个几十篇文章也下不来的…所以接下来进入容器相关的流程后，对Spring源码还不太熟悉的朋友，可以先找资料研究下Spring的源码，包括后续进入容器的refresh过

上篇文章结束了prepareEnvironment方法的分析，本篇继续SpringApplication的run方法往下走，看一个比较简单的点——banner打印所谓banner就是SpringBoot应用启动的时候打印在控制台的一个logo涉及到的代码就是下面这行printBanner在这之前，先简单说下上面的这行configureIgnoreBeanInfo private void configureIgnoreBeanInfo(ConfigurableEnvironment env

最近很多篇都是围绕prepareEnvironment方法在分析，上篇补充了ApplicationEnvironmentPreparedEvent事件的处理，相当于下面的listeners.environmentPrepared方法就结束掉了，本文就把这个方法中剩下的几行代码收下尾 private ConfigurableEnvironment prepareEnvironment(SpringApplicationRunListeners listeners, ApplicationArgumen

最近两篇文章主要分析了ConfigFileApplicationListener对事件ApplicationEnvironmentPreparedEvent的处理，包括EnvironmentPostProcessor扩展点和系统配置文件的加载，而之前也提到过，实际上有很多监听者都会监听该事件的发布，本文对其它几个监听者的相关处理做个大致的介绍首先看下收到回掉的监听者列表ConfigFileApplicationListener以及介绍地很详细了，接下来对剩下的监听器做逐一分析AnsiOutputAp

上篇文章介绍了EnvironmentPostProcessor接口，在ConfigFileApplicationListener的接口实现中调用了addPropertySources，这个方法第一行添加了一个提供随机数的RandomValuePropertySource，第二行涉及到配置文件的加载，还没有进行说明，本文就继续分析这一加载流程 protected void addPropertySources(ConfigurableEnvironment environment, ResourceL

本文将重点介绍SpringBoot提供给我们的另一个扩展点EnvironmentPostProcessor，它允许我们到任意的指定目录、以任意的方式加载一组配置，并赋予任意的优先级上文对prepareEnvironment方法的configureEnvironment做了一个收尾，本文继续看第三行代码listeners.environmentPrepared private ConfigurableEnvironment prepareEnvironment(SpringApplication.

Environment中有个属性ActiveProfiles，是将来要激活的配置本文主要对上篇文章剩下的一个点做个收尾上篇文章讲了配置的优先级，主要涉及到getOrCreateEnvironment和configureEnvironment两个方法其中configureEnvironment方法还剩最后一行configureProfiles没有提到 protected void configureEnvironment(ConfigurableEnvironment environment,

上篇文章分析了PropertySource，描述它是一组属性的集合，算是对接下来Environment环节的铺垫，它可以看做项目的运行时环境，是系统运行的基础，最此之前，我们先来聊一下系统配置的优先级回想一下之前的面试，有没有遇到过这样的问题：在一个springboot项目中，命令行参数、系统环境变量、配置文件，它们的优先级是怎么样的？这个问题也将在本文中，从源码的角度给出答案本文的主角，即SpringApplication的run方法中，这行prepareEnvironment这个方法的入参是Sp

上篇文章分析了对ApplicationStartingEvent事件的处理，接下来回到SpringApplication.run()方法的流程本文主要着眼于基础环境的准备，涉及到如下两行代码首先第一行，new了一个DefaultApplicationArguments，其作用是把项目的启动参数保存起来ApplicationArguments applicationArguments = new DefaultApplicationArguments(args);public class Defau

上篇文章分析了SpringBoot事件发布机制的大致原理，并且提到了SpringBoot启动过程中的第一个事件ApplicationStartingEvent，以及监听了该事件的四个监听器：DelegatingApplicationListenerLoggingApplicationListenerLiquibaseServiceLocatorApplicationListenerBackgroundPreinitializer首先还是先简单说下为什么这四个监听器能监听到Application

上篇文章从springboot应用的启动开始说起，分析完了SpringApplication对象的初始化流程 public static ConfigurableApplicationContext run(Class<?>[] primarySources, String[] args) { return (new SpringApplication(primarySources)).run(args); }这篇文章开始分析后面的run方法 publ

通常来说，一个基本的SpringBoot应用的启动类长这个样子：@SpringBootApplicationpublic class Application { public static void main(String[] args) { SpringApplication.run(Application.class, args); }}我们从启动类开始，分析SpringBoot的源码流程，进入run方法 public static Configurab