【Spring】——IoC 之 BeanDefinition 注册表:BeanDefinitionRegistry
将定义 Bean 的资源文件解析成 BeanDefinition 后需要将其注入容器中,这个过程由 BeanDefinitionRegistry 来完成。
将定义 Bean 的资源文件解析成 BeanDefinition 后需要将其注入容器中,这个过程由 BeanDefinitionRegistry 来完成。
在开始分析 InstantiationStrategy 之前,我们先来简单回顾下 Bean 的实例化过程。
在实例化 Bean 阶段,我们从 BeanDefinition 得到的并不是我们最终想要的 Bean 实例,而是 BeanWrapper 实例。
在上篇文章中小编分析了 Spring ConversionService 类型转换体系,相信各位都对其有了一个清晰的认识,这篇博客将利用 ConversionService 体系来实现自己的类型转换器。
我们知道不管 Bean 对象里面的属性时什么类型,他们都是通过 XML 、Properties 或者其他方式来配置这些属性对象类型的。
在文章 [《【 Spring】—— IoC 之深入分析 BeanFactoryPostProcessor》](http://svip.iocoder.cn/Spring/IoC-BeanFactoryPostProcessor) 中提到,BeanFactoryPostProcessor 作用与 BeanDefinition 完成加载之后与 Bean 实例化之前,是 Spring 提供的一种强大的扩展机制
在博客 《【 Spring】—— IoC 之深入分析 PropertyPlaceholderConfigurer》 中了解了 PropertyPlaceholderConfigurer 内部实现原理,它允许我们在 XML 配置文件中使用占位符并将这些占位符所代表的资源单独配置到简单的 properties 文件中来加载。
在上文 《【Spring】—— IoC 之深入分析 BeanFactoryPostProcessor》 中,介绍了 BeanFactoryPostProcessor,知道 BeanFactoryPostProcessor 作用域容器启动阶段,可以对解析好的 BeanDefinition 进行定制化处理,而其中 PropertyPlaceholderConfigurer 是其一个非常重要的应用,
在这篇文章中提到 BeanPostProcessor 是 Spring 提供一种扩展机制,该机制允许我们在 Bean 实例化之后初始化之际对 Bean 进行增强处理(前、后置处理)。
在分析 Spring Bean 实例化过程中提到 Spring 并不是一启动容器就开启 bean 的实例化进程,只有当客户端通过显示或者隐式的方式调用 BeanFactory 的 #getBean(...) 方法来请求某个实例对象的时候,它才会触发相应 bean 的实例化进程。