之前的文章捋了捋PostProcessor的处理流程，其中有一个特别重要的PostProcessor：ConfigurationClassPostProcessor，即配置类的后置处理器（参与BeanFactory的建造）
主要功能：
- 解析被 @Configuration修饰的配置类
- 解析 @ComponentScan扫描的包
- 解析 @ComponentScans扫描的包
- 解析被 @Import注解修饰的类
上一篇我们捋了捋invokeBeanFactoryPostProcessors()的整体逻辑，由于ConfigurationClassPostProcessor实现了BeanDefinitionRegistryPostProcessor所以他会在invokeBeanFactoryPostProcessors()方法中被处理，我们debug到invokeBeanFactoryPostProcessors()方法中
ConfigurationClassPostProcessor是在第二步（处理子类，详见上一篇文章）中，即处理实现了BeanDefinitionRegistryPostProcessor接口的步骤中被处理的，而且发现有一点就是我刚开始使用配置文件进行配置的时候，整个debuginvokeBeanFactoryPostProcessors()方法的过程中都没有看到ConfigurationClassPostProcessor这个类，当我使用配置类时，才在上图的位置发现了ConfigurationClassPostProcessor
继续执行，进入对子类单独处理的遍历中
在这里会进入到ConfigurationClassPostProcessor中实现的postProcessBeanDefinitionRegistry ( BeanDefinitionRegistry registry ) 方法
这里会先生成一个registryId，用做容器中Bean的唯一标识，然后判断这个传入的registry是否已经被处理过，处理过，抛出异常，未被处理过，则将其registryId添加进已经处理的集合对象中，之后就会进入核心处理环节，如下图
processConfigBeanDefinitions() 筛选Bean进入该方法后，先创建了一个用于存放BeanDefinitionHolder的对象集合List
上图中的遍历筛选部分的代码
for ( String beanName : candidateNames ) {
BeanDefinition beanDef = registry.getBeanDefinition ( beanName ) ;
if ( beanDef.getAttribute ( ConfigurationClassUtils.CONFIGURATION_CLASS_ATTRIBUTE) != null ) {
if ( logger.isDebugEnabled ()) {
logger.debug ( "Bean definition has already been processed as a configuration class: " + beanDef ) ;
}
}
else if ( ConfigurationClassUtils.checkConfigurationClassCandidate( beanDef, this.metadataReaderFactory ))；
configCandidates.add ( new BeanDefinitionHolder ( beanDef, beanName )) ;
}
}
复制代码
上面的for循环，依次获取BeanDefinition，并进行两个判断：
1. 是否包含属性ConfigurationClassUtils.CONFIGURATION_CLASS_ATTRIBUTE)
2. 判断当前BeanDefinition是否是一个配置类，并根据注解类型为BeanDefinition设置属性(以便后续进行调用），这个主要逻辑在checkConfigurationClassCandidate()方法中，后面会单出一篇文章详细介绍这个函数，它里面的主要逻辑是：
-
设置为full/lite
- 如果被@Configuration修饰则为full
- 如果被@Bean、@Component、@ComponentScan、@Import、@ImportResoure修饰则属性值设为lite
-
如果配置类上被order修饰，则为BeanDefinition添加order参数
遍历判断后，如果未发现有配置相关的类，则直接返回
对添加@Order注解的类，进行排序操作
继续判断当前类型是否是SingletonBeanRegistry类型（进行BeanName生成器的配置）
解析配置类之后就到了重要的一步：解析配置类
先实例化ConfigurationClassParser类+初始化相关参数（如下图中注释）
之后进入配置类的解析工作parser.parse()
此处会解析带有@ComponentScan、@ComponentScans、@Import、@ImportResource、@Bean、@Controller的BeanDefinition 但有一点需要注意，这里只是把两种类（添加了@Configuration注解的类和通过ComponentScan注解扫描的类）加入到BeanDefinitionMap中，其余的方式（@Import注册的类、@Bean方法定义的类）在parse()这一步不会被解析为BeanDefinition放进BeanDefinitionMap中（实际在this.reader.loadBeanDefinitions()中实现，只是发现流程是这样，欢迎知道原因的同学踢踢我(｡ì _ í｡)抱拳多谢.gif）
之后就进入了递归调用processConfigurationClass()方法来处理配置类的内部类所带注解、内部类的内部类所带注解（如果有的话）……
呃。太长叻(˶‾᷄ ⁻̫ ‾᷅˵)
下篇我们继续详细看下递归调用的processConfigurationClass()方法(｡･ω･｡)ﾉ
