1. 카테고리 :
@SpringBootApplication
public class Application{
public static void main(String[] args){
SpringApplication.run(Application.class,args);
}
}초점 @SpringBootApplication하고있다 (SpringApplication.run ())
SpringBootApplication 뒤에 비밀
1 2 3 4 5 6 7 8 9 10 11 12 |
@Target (ElementType.TYPE)
@Retention (RetentionPolicy.RUNTIME)
@Documented
@Inherited
@SpringBootConfiguration
@EnableAutoConfiguration
@ComponentScan (excludeFilters = {
@filter (TYPE = FilterType.CUSTOM 클래스 = TypeExcludeFilter.class)
@filter (TYPE = FilterType .CUSTOM, 클래스 = AutoConfigurationExcludeFilter.class)})
공공 @interface의 SpringBootApplication {
...}
|
@Configuration @EnableAutoConfiguration @ComponentScan
@Configuration
@Configuration 여기에, 그것은, SpringBoot은 지역 사회에 기반을 둔 구성은 JavaConfig, 그래서 여기에 표시 @Configuration 후 수업을 시작하는 것이 좋습니다 사용 구성 봄의 IOC의 컨테이너 구성 클래스 @ JavaConfig 양식입니다, 우리에게 낯선 없다 구성 클래스 자체는 실제로 IoC 컨테이너이다.
검토, 차이와 XML의 설정 구성에 따라 몇 가지 간단한 예 :
- 발현 수준의 양식
XML 구성 방식에 따라이있다 :1 2 3 4 5 6 7
<XML 버전 = "1.0" "UTF-8"인코딩 =?> <콩의 xmlns = "http://www.springframework.org/schema/beans" 에 xmlns :이 xsi = "http://www.w3.org / 2001 / 된 XMLSchema 인스턴스 " : http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-3.0.xsd"XSI =의 schemaLocation " 기본적으로 게으른 -init = "진정한"> <! - 콩定义-> </ 콩>
JavaConfig 기반 구성은 이것이다 :
1 2 3 4 |
@Configuration
공용 클래스 MockConfiguration {
// 빈定义
}
|
모든 표시 자바 클래스 정의는 @Configuration JavaConfig 구성 클래스입니다.
- 로그인 빈 정의 수준
XML의 형태로 구성에 따라이있다 :1 2 3
<빈 ID = "mockService"클래스 = ".. MockServiceImpl"> ... </ 콩>
양식 기반 구성 JavaConfig은 이것이다 :
1 2 3 4 5 6 7 |
@Configuration
공용 클래스 MockConfiguration {
@Bean
공공 MockService mockService () {
) 새로운 MockServiceImpl를 (반환;
}
}
|
빈은 Spring IoC 컨테이너, 메소드 정의 된 Bean의 ID에 대한 기본 이름을 등록 된 @Bean 표시된 모든 방법, 반환 값이 정의됩니다.
- 발현 수준 의존 관계 주입
콩 및 콩 사이 익스프레스 종속성 일반적으로 XML 형태이다 :
1 2 3 4 5 |
<빈 ID = "mockService"클래스 = ".. MockServiceImpl">
<때에 프로퍼티 이름 = "dependencyService"REF = "dependencyService"/>
</ 빈>
<빈 ID = "dependencyService"클래스 = "DependencyServiceImpl"> </ 콩>
|
양식 기반 구성 JavaConfig은 이것이다 :
1 2 3 4 5 6 7 8 9 10 11 12 |
@Configuration
공용 클래스 MockConfiguration {
@Bean
공공 MockService mockService () {
반환 새 MockServiceImpl (dependencyService ());
}
@Bean
공공 DependencyService dependencyService () {
) 새로운 DependencyServiceImpl를 (반환;
}
}
|
당신은, 콩은 다른 콩에 의존하는 클래스 JavaConfig를 정의하면 직접에 해당하는 빈을 생성 메서드를 호출합니다.
@ComponentScan
이 댓글은 ComponentScan 기능 @ 실제로 자동으로 스캔 및로드 구성 요소 또는 빈 정의, 결국 이러한 bean 정의 (예 : @Component 및 @Repository 등) 자격이되는 XML 구성 요소에 해당, 봄, 매우 중요하다 @ComponentScan IOC는 컨테이너에로드.
우리는 세분화 할 수 있습니다 자동 스캔 basePackages에 의해 @ComponentScan 같은 사용자 정의 같은 속성의 범위를 지정하지 않을 경우 기본값은 클래스 선언 @ComponentScan 거짓말에서 스캔 패키지를 달성하는 스프링 프레임 워크가 될 것입니다.
참고 : 기본 basePackages을 지정하지 않기 때문에 그래서 SpringBoot이 가장 루트 패키지에 배치되어 수업을 시작합니다.
깊이 탐사 SpringApplication 실행 과정
다음과 같이 실행 방법은 SpringApplication 우리가이 여행의 주요 라인 구현, 방법의 주요 흐름은 대략 요약 될 수있다 :
1） 如果我们使用的是SpringApplication的静态run方法，那么，这个方法里面首先要创建一个SpringApplication对象实例，然后调用这个创建好的SpringApplication的实例方法。在SpringApplication实例初始化的时候，它会提前做几件事情：
- 根据classpath里面是否存在某个特征类（org.springframework.web.context.ConfigurableWebApplicationContext）来决定是否应该创建一个为Web应用使用的ApplicationContext类型。
- 使用SpringFactoriesLoader在应用的classpath中查找并加载所有可用的ApplicationContextInitializer。
- 使用SpringFactoriesLoader在应用的classpath中查找并加载所有可用的ApplicationListener。
- 推断并设置main方法的定义类。
2） SpringApplication实例初始化完成并且完成设置后，就开始执行run方法的逻辑了，方法执行伊始，首先遍历执行所有通过SpringFactoriesLoader可以查找到并加载的SpringApplicationRunListener。调用它们的started()方法，告诉这些SpringApplicationRunListener，“嘿，SpringBoot应用要开始执行咯！”。
3） 创建并配置当前Spring Boot应用将要使用的Environment（包括配置要使用的PropertySource以及Profile）。
4） 遍历调用所有SpringApplicationRunListener的environmentPrepared()的方法，告诉他们：“当前SpringBoot应用使用的Environment准备好了咯！”。
5） 如果SpringApplication的showBanner属性被设置为true，则打印banner。
6） 根据用户是否明确设置了applicationContextClass类型以及初始化阶段的推断结果，决定该为当前SpringBoot应用创建什么类型的ApplicationContext并创建完成，然后根据条件决定是否添加ShutdownHook，决定是否使用自定义的BeanNameGenerator，决定是否使用自定义的ResourceLoader，当然，最重要的，将之前准备好的Environment设置给创建好的ApplicationContext使用。
7） ApplicationContext创建好之后，SpringApplication会再次借助Spring-FactoriesLoader，查找并加载classpath中所有可用的ApplicationContext-Initializer，然后遍历调用这些ApplicationContextInitializer的initialize（applicationContext）方法来对已经创建好的ApplicationContext进行进一步的处理。
8） 遍历调用所有SpringApplicationRunListener的contextPrepared()方法。
9） 最核心的一步，将之前通过@EnableAutoConfiguration获取的所有配置以及其他形式的IoC容器配置加载到已经准备完毕的ApplicationContext。
10） 遍历调用所有SpringApplicationRunListener的contextLoaded()方法。
11） 调用ApplicationContext的refresh()方法，完成IoC容器可用的最后一道工序。
12） 查找当前ApplicationContext中是否注册有CommandLineRunner，如果有，则遍历执行它们。
13） 正常情况下，遍历执行SpringApplicationRunListener的finished()方法、（如果整个过程出现异常，则依然调用所有SpringApplicationRunListener的finished()方法，只不过这种情况下会将异常信息一并传入处理）
去除事件通知点后，整个流程如下：
总结
到此，SpringBoot的核心组件完成了基本的解析，综合来看，大部分都是Spring框架背后的一些概念和实践方式，SpringBoot只是在这些概念和实践上对特定的场景事先进行了固化和升华，而也恰恰是这些固化让我们开发基于Sping框架的应用更加方便高效。
