标签：enc 为什么 ram code embed prepare 需要 定义 env
一、前言上篇文章我们深入分析了SpringBoot的一站式启动流程。然后我们知道SpringBoot的主要功能都是依靠它内部很多的扩展点来完成的，那毋容置疑，这些扩展点是我们应该深入了解的，那么本次且听我一一道来SpringBoot的各类扩展点。
从命名我们就可以知道它是一个监听者，那纵观整个启动流程我们会发现，它其实是用来在整个启动流程中接收不同执行点事件通知的监听者。源码如下：
public interface SpringApplicationRunListener {
void starting();
void environmentPrepared(ConfigurableEnvironment environment);
void contextPrepared(ConfigurableApplicationContext context);
void contextLoaded(ConfigurableApplicationContext context);
void finished(ConfigurableApplicationContext context, Throwable exception);
}
对于开发者来说，基本没有什么常见的场景要求我们必须实现一个自定义的SpringApplicationRunListener，即使是SpringBoot中也只默认实现了一个org.springframework.boot.context.eventEventPublishingRunListener, 用来在SpringBoot的整个启动流程中的不同时间点发布不同类型的应用事件(SpringApplicationEvent)。那些对这些应用事件感兴趣的ApplicationListener可以接受并处理(这也解释了为什么在SpringApplication实例化的时候加载了一批ApplicationListener，但在run方法执行的过程中并没有被使用)。
如果我们真的在实际场景中自定义实现SpringApplicationRunListener,有一个点需要注意：任何一个SpringApplicationRunListener实现类的构造方法都需要有两个构造参数，一个参数的类型就是我们的org.springframework.boot.SpringApplication,另外一个参数就是args参数列表的String[]:
package com.hafiz.springbootdemo;
import org.springframework.boot.SpringApplication;
import org.springframework.boot.SpringApplicationRunListener;
import org.springframework.context.ConfigurableApplicationContext;
import org.springframework.core.env.ConfigurableEnvironment;
/**
* @author hafiz.zhang
* @description:
* @date Created in 2018/6/7 20:07.
*/
public class DemoSpringApplicationRunListener implements SpringApplicationRunListener {
private final SpringApplication application;
private final String[] args;
public DemoSpringApplicationRunListener(SpringApplication sa, String[] args) {
this.application = sa;
this.args = args;
}
@Override
public void starting() {
System.out.println("自定义starting");
}
@Override
public void environmentPrepared(ConfigurableEnvironment environment) {
System.out.println("自定义environmentPrepared");
}
@Override
public void contextPrepared(ConfigurableApplicationContext context) {
System.out.println("自定义contextPrepared");
}
@Override
public void contextLoaded(ConfigurableApplicationContext context) {
System.out.println("自定义contextLoaded");
}
@Override
public void finished(ConfigurableApplicationContext context, Throwable exception) {
System.out.println("自定义finished");
}
}接着，我们还要满足SpringFactoriesLoader的约定，在当前SpringBoot项目的classpath下新建META-INF目录，并在该目录下新建spring.fatories文件，文件内容如下:
org.springframework.boot.SpringApplicationRunListener=\
com.hafiz.springbootdemo.DemoSpringApplicationRunListener
ApplicationListener不是新东西，它属于Spring框架对Java中实现的监听者模式的一种框架实现，这里需要注意的是：对于刚接触SpringBoot，但是对于Spring框架本身又没有过多地接触的开发人员来说，可能会将这个名字与SpringApplicationRunListener弄混。
如果我们有需要为SpringBoot应用添加我们自定义的ApplicationListener,那么有两种方式：
通过SpringApplication.addListeners(…)或者SpringApplication.setListener(…)方法添加一个或者多个自定义的ApplicationListener。
org.springframework.context.ApplicationListener=org.springframework.boot.ClearCachesApplicationListener,org.springframework.boot.builder.ParentContextCloserApplicationListener,org.springframework.boot.context.FileEncodingApplicationListener,org.springframework.boot.context.config.AnsiOutputApplicationListener,org.springframework.boot.context.config.ConfigFileApplicationListener,org.springframework.boot.context.config.DelegatingApplicationListener,org.springframework.boot.liquibase.LiquibaseServiceLocatorApplicationListener,org.springframework.boot.logging.ClasspathLoggingApplicationListener,org.springframework.boot.logging.LoggingApplicationListener3.ApplicationContextInitializer
这货也是Spring框架原有的东西，这个类的主要作用就是在ConfigurableApplicationContext类型(或者子类型)的ApplicationContext做refresh之前，允许我们对ConfiurableApplicationContext的实例做进一步的设置和处理。
我们要实现一个自定义的ApplicationContextInitializer也很简单，它只有一个方法需要我们的自定义类实现：
package com.hafiz.springbootdemo;
import org.springframework.context.ApplicationContextInitializer;
import org.springframework.context.ConfigurableApplicationContext;
/**
* @author hafiz.zhang
* @description:
* @date Created in 2018/6/7 20:33.
*/
public class DemoApplicationContextInitializer implements ApplicationContextInitializer {
@Override
public void initialize(ConfigurableApplicationContext applicationContext) {
System.out.println("自定义DemoApplicationContextInitializer的initialize方法");
}
}然后也需要在项目自定义的META-INF/spring.factories文件中注册：
org.springframework.context.ApplicationContextInitializer= com.hafiz.springbootdemo.DemoApplicationContextInitializer不过我们一般情况下是不需要自定义一个ApplicationContextInitializer,即使SpringBoot框架默认也只有以下四个实现而已：
org.springframework.context.ApplicationContextInitializer=org.springframework.boot.context.ConfigurationWarningsApplicationContextInitializer,org.springframework.boot.context.ContextIdApplicationContextInitializer,org.springframework.boot.context.config.DelegatingApplicationContextInitializer,org.springframework.boot.context.embedded.ServerPortInfoApplicationContextInitializerCommandLineRunner并不是Spring框架原有的概念，它属于SpringBoot应用特定的回调扩展接口：
public interface CommandLineRunner {
/**
* Callback used to run the bean.
* @param args incoming main method arguments
* @throws Exception on error
*/
void run(String... args) throws Exception;
}关于这货，我们需要关注的点有两个：
当前SpringBoot应用的ApplicationContext中的所有CommandLinerRunner都会被加载执行(无论是手动注册还是被自动扫描注册到IoC容器中)。
跟其他几个扩展点接口类型相似，我们建议CommandLineRunner的实现类使用@org.springframework.core.annotation.Order进行标注或者实现org.springframework.core.Ordered接口，便于对他们的执行顺序进行排序调整，这是非常有必要的，因为我们不希望不合适的CommandLineRunner实现类阻塞了后面其他CommandLineRunner的执行。这个接口非常有用和重要，我们需要重点关注。
上篇文章我们知道了，@EnableAutoConfiguration借助SpringFactoriesLoader可以将标注了@Configuration这个注解的JavaConfig类一并汇总并加载到最终的ApplicationContext，这么说只是很简单的解释，其实基于@EnableAutoConfiguration的自动配置功能拥有非常强大的调控能力。比如我们可以通过配合基于条件的配置能力或定制化加载顺序，对自动化配置进行更加细粒度的调整和控制。
这个基于条件的自动配置来源于Spring框架中的"基于条件的配置"特性。在Spring框架中，我们可以使用@Conditional这个注解配合@Configuration或@Bean等注解来干预一个配置或bean定义是否能够生效，它最终实现的效果或者语义类如下伪代码：
if (复合@Conditional规定的条件) {
加载当前配置（Enable Current Configuration）或者注册当前bean定义;
}要实现基于条件的配置，我们需要通过@Conditional注解指定自己Condition实现类就可以了(可以应用于类型Type的注解或者方法Method的注解)
@Conditional({DemoCondition1.class, DemoCondition2.class})最重要的是，@Conditional注解可以作为一个Meta Annotaion用来标注其他注解实现类，从而构建各种复合注解，比如SpringBoot的autoconfigre模块就基于这一优良的革命传统，实现了一批这样的注解(在org.springframework.boot.autoconfigure.condition包下):
有了这些复合Annotation的配合，我们就可以结合@EnableAutoConfiguration实现基于条件的自动配置了。其实说白了，SpringBoot能够如此的盛行，很重要的一部分就是它默认提供了一系列自动配置的依赖模块，而这些依赖模块都是基于以上的@Conditional复合注解实现的，这也就说明这些所有的依赖模块都是按需加载的，只有复合某些特定的条件，这些依赖模块才会生效，这也解释了为什么自动配置是“智能”的。
在实现自动配置的过程中，我们除了可以提供基于条件的配置之外，我们还能对当前要提供的配置或组件的加载顺序进行个性化调整，以便让这些配置或者组件之间的依赖分析和组装能够顺利完成。
最经典的是我们可以通过使用@org.springframework.boot.autoconfigure.AutoConfigureBefore或者@org.springframework.boot.autoconfigure.AutoConfigureAfter让当前配置或者组件在某个其他组件之前或者之后进行配置。例如，假如我们希望某些JMX操作相关的bean定义在MBeanServer配置完成以后在进行配置，那我们就可以提供如下配置：
@Configuration
@AutoConfigureAfter(JmxAutoConfiguration.class)
public class AfterMBeanServerReadyConfiguration {
@Autowired
MBeanServer mBeanServer;
// 通过@Bean添加其他必要的bean定义
}截至目前，我们已经完成了对SpringBoot的核心组件一一解析，总结来说，SpringBoot中大部分东西都是Spring框架中已经存在原有概念和实践方式，SpringBoot只是在这基础上对特定的场景进行定制、固化以及升级。然后正式这些固化升级让我们感受到了SpringBoot开发的便捷以及高效。
然后，你会突然发现，SpringBoot原来是这么的简单，其中并无任何秘密。但是Spring团队通过对Spring应用的固化和升级，让SpringBoot可以完成开发只关注业务逻辑开发的神奇事件，整个开发过程更加高效以及简单，但是对于SpringBoot的设计者来说，他们并没有耗费巨大的精力。另一方面来说，开箱即用才是未来发展的趋势，"约定大于配置(Convention Over Configuration)"也必将统领江山！
阿豪说
学到了？请我喝杯咖啡吧~
标签：enc 为什么 ram code embed prepare 需要 定义 env
原文地址：https://blog.51cto.com/15047484/2560245
