Spring处理@Configuration的分析
Spring处理@Configuration的分析
声明:本文若有任何纰漏、错误,还请不吝指出!
序言
@Configuration
注解在SpringBoot
中作用很大,且不说SpringBoot
中的外部化配置,一些第三方组件也是通过这个注解完成整合的,常用的比如说mybatis
,就是利用了@Configuration
这个注解来实现的。
在注解类中,还可以使用@Bean
的方式向Spring
容器中,注入一些我们自定义的组件。
在SpringBoot
中各种Enable
又是如何实现的?和@Configuration
又有什么联系呢?
这就要了解Spring
是怎么对待被@Configuration
所注解的类。
环境
SpringBoot 2.2.6RELEASE
Spring 5.2.5.RELEASE
正文
注解依附于具体的Java
类,所以如果想获取注解的信息,必须先将类加载进来,才能从Class
对象获取到其注解元信息。
好在Spring
容器启动之前,已经把所有需要加载的Bean,封装成一个BeanDefinition
对象,最终注册到BeanDefinitionRegistry
中。
BeanDefinition
包含了一个Bean
所有的信息,自然也包含了它的元注解信息。
有了这个就能轻而易举的获取到标注有@Configuration
注解的BeanDefinition
,从而去处理这个配置类拥有的各种配置信息。
有了BeanDefinition
之后,下面一步就是要进行Bean的实例化了。如果一个Bean
被实例化后,就没有可操作的机会了,因此Spring
在Bean
的实例化前预留了一些自定义的处理时机。
BeanFactoryPostProcessor
就是这样的一个功能,用于在Bean
实例化之前,做一些其他的处理操作。
对配置类的处理,也正是利用了这一预留点。
BeanDefinitionRegistryPostProcessor
处理配置类,第一步就要从茫茫的BeanDefinition
中,找出哪些是配置类。
容器开始启动之前的一些准备动作,这里不说明,主要是扫描classpath
,然后将生成BeanDefinition
。
直接从容器的启动开始简单下调用栈
Spring容器真正开始启动的是从这里开始的org.springframework.context.support.AbstractApplicationContext#refresh
,在这个方法中,会去执行所有的BeanFactoryPostProcessor
。
通过一个委托类org.springframework.context.support.PostProcessorRegistrationDelegate
,执行所有的BeanFactoryPostProcessor
后置处理逻辑。
BeanFactoryPostProcessor
有一个子接口是BeanDefinitionRegistryPostProcessor
,这个接口的主要作用就是在其他后置处理执行之前,额外注册一些BeanDefinition
进来。
想想在配置类中使用的@Import
和@Bean
,就可以猜到,这些注解的处理就是由这个处理器进行处理的。
BeanDefinitionRegistryPostProcessor
和BeanFactoryPostProcessor
是放到一起处理的,只不过BeanDefinitionRegistryPostProcessor
的执行时机,早于BeanFactoryPostProcessor
的执行时机。
// org.springframework.context.support.PostProcessorRegistrationDelegate
public static void invokeBeanFactoryPostProcessors(
ConfigurableListableBeanFactory beanFactory, List<BeanFactoryPostProcessor> beanFactoryPostProcessors) {
Set<String> processedBeans = new HashSet<>();
// 如果BeanFactory同时又是一个BeanDefinitionRegistry的话
// 例如 DefaultListaleBeanFactory
if (beanFactory instanceof BeanDefinitionRegistry) {
BeanDefinitionRegistry registry = (BeanDefinitionRegistry) beanFactory;
List<BeanFactoryPostProcessor> regularPostProcessors = new ArrayList<>();
List<BeanDefinitionRegistryPostProcessor> registryProcessors = new ArrayList<>();
// 如果有直接注册到Context的后置处理器,
// 先执行直接添加到ApplicationContext的BeanDefinitionRegistryPostProcessor处理器
for (BeanFactoryPostProcessor postProcessor : beanFactoryPostProcessors) {
if (postProcessor instanceof BeanDefinitionRegistryPostProcessor) {
BeanDefinitionRegistryPostProcessor registryProcessor =
(BeanDefinitionRegistryPostProcessor) postProcessor;
// 执行BeanDefinitionRegistryPostProcessor处理器
registryProcessor.postProcessBeanDefinitionRegistry(registry);
// BeanDefinitionRegistryPostProcessor同时又是一个BeanFactoryPostProcessor
// 待所有的BeanDefinitionRegistryPostProcessor执行完后,再来执行它
registryProcessors.add(registryProcessor);
}
else {
// 加入到BeanFactoryPostProcessor处理器集合中,待所有的BeanDefinitionRegistryPostProcessor执行完后,来执行它
regularPostProcessors.add(postProcessor);
}
}
List<BeanDefinitionRegistryPostProcessor> currentRegistryProcessors = new ArrayList<>();
// 对从BeanDefinitionRegistry中的BeanDefinition做后置处理
// 先执行被@PriorityOrdered注解的BeanDefinitionRegistryPostProcessor
// 并且按排序大小进行优先级排序
// 根据类型,从BeanDefinitionRegistry中查找出所有的BeanDefinitionRegistryPostProcessor的是实现类,及子类
String[] postProcessorNames =
beanFactory.getBeanNamesForType(BeanDefinitionRegistryPostProcessor.class, true, false);
for (String ppName : postProcessorNames) {
// 使用@PriorityOrdered注解的先查找出来
if (beanFactory.isTypeMatch(ppName, PriorityOrdered.class)) {
currentRegistryProcessors.add(beanFactory.getBean(ppName, BeanDefinitionRegistryPostProcessor.class));
processedBeans.add(ppName);
}
}
// 按编号大小排序,升序排列
sortPostProcessors(currentRegistryProcessors, beanFactory);
registryProcessors.addAll(currentRegistryProcessors);
// 执行BeanDefinitionRegistryPostProcessor
invokeBeanDefinitionRegistryPostProcessors(currentRegistryProcessors, registry);
currentRegistryProcessors.clear();
// 处理被注解@Ordered标注的BeanDefinitionRegistryPostProcessor,
// 并且按排序后排序后执行
// 根据类型,从BeanDefinitionRegistry中查找出所有的BeanDefinitionRegistryPostProcessor的是实现类,及子类
postProcessorNames = beanFactory.getBeanNamesForType(BeanDefinitionRegistryPostProcessor.class, true, false);
for (String ppName : postProcessorNames) {
// 没被处理过且被注解@Ordered
if (!processedBeans.contains(ppName) && beanFactory.isTypeMatch(ppName, Ordered.class)) {
currentRegistryProcessors.add(beanFactory.getBean(ppName, BeanDefinitionRegistryPostProcessor.class));
processedBeans.add(ppName);
}
}
sortPostProcessors(currentRegistryProcessors, beanFactory);
registryProcessors.addAll(currentRegistryProcessors);
// 执行BeanDefinitionRegistryPostProcessor
invokeBeanDefinitionRegistryPostProcessors(currentRegistryProcessors, registry);
currentRegistryProcessors.clear();
// 再去执行其他的剩下的所有BeanDefinitionRegistryPostProcessor
boolean reiterate = true;
while (reiterate) {
reiterate = false;
postProcessorNames= beanFactory.getBeanNamesForType(BeanDefinitionRegistryPostProcessor.class, true, false);
for (String ppName : postProcessorNames) {
if (!processedBeans.contains(ppName)) {
currentRegistryProcessors.add(beanFactory.getBean(ppName, BeanDefinitionRegistryPostProcessor.class));
processedBeans.add(ppName);
reiterate = true;
}
}
sortPostProcessors(currentRegistryProcessors, beanFactory);
registryProcessors.addAll(currentRegistryProcessors);
invokeBeanDefinitionRegistryPostProcessors(currentRegistryProcessors, registry);
currentRegistryProcessors.clear();
}
// BeanDefinitionRegistryPostProcessor也是一个BeanFactoryPostProcessor
// 下面这部分就是执行postProcessBeanFactory方法,
// 会在@Configuration的proxyBeanMethods为true时对配置类做一个CGLIB增强,
// 表示对配置类中的BeanMethod创建时,使用代理创建
// 将增强后的类,替换到其BeanDefinition#setBeanClass
invokeBeanFactoryPostProcessors(registryProcessors, beanFactory);
// 最后再执行直接注册到到ApplicationContext中的BeanFactoryPostProcessor
invokeBeanFactoryPostProcessors(regularPostProcessors, beanFactory);
}
else {
// 处理直接通过ApplicationContext实例注册的BeanFactoryPostProcessor
invokeBeanFactoryPostProcessors(beanFactoryPostProcessors, beanFactory);
}
// 上面就执行过了定义的所有的BeanDefinitionRegistryPostProcessor,以及实现的
// BeanFactoryPostProcessor#postProcessBeanFactory方法
// 接下来回去执行所有的BeanFactoryPostProcessor处理器
// 查找出所有注册的类型为BeanFactoryPostProcessor的BeanDefinition的name数组
String[] postProcessorNames =
beanFactory.getBeanNamesForType(BeanFactoryPostProcessor.class, true, false);
// 分别归类出使用@PriorityOrdered 和 @Ordered注解和没有使用的
List<BeanFactoryPostProcessor> priorityOrderedPostProcessors = new ArrayList<>();
List<String> orderedPostProcessorNames = new ArrayList<>();
List<String> nonOrderedPostProcessorNames = new ArrayList<>();
for (String ppName : postProcessorNames) {
if (processedBeans.contains(ppName)) {
// 处理过的,不用重复处理
}
else if (beanFactory.isTypeMatch(ppName, PriorityOrdered.class)) {
priorityOrderedPostProcessors.add(beanFactory.getBean(ppName, BeanFactoryPostProcessor.class));
}
else if (beanFactory.isTypeMatch(ppName, Ordered.class)) {
orderedPostProcessorNames.add(ppName);
}
else {
nonOrderedPostProcessorNames.add(ppName);
}
}
// 优先处理 PriorityOrdered.
sortPostProcessors(priorityOrderedPostProcessors, beanFactory);
invokeBeanFactoryPostProcessors(priorityOrderedPostProcessors, beanFactory);
// 其次 Ordered.
List<BeanFactoryPostProcessor> orderedPostProcessors = new ArrayList<>(orderedPostProcessorNames.size());
for (String postProcessorName : orderedPostProcessorNames) {
orderedPostProcessors.add(beanFactory.getBean(postProcessorName, BeanFactoryPostProcessor.class));
}
sortPostProcessors(orderedPostProcessors, beanFactory);
invokeBeanFactoryPostProcessors(orderedPostProcessors, beanFactory);
//最后普通的 BeanFactoryPostProcessor
List<BeanFactoryPostProcessor> nonOrderedPostProcessors = new ArrayList<>(nonOrderedPostProcessorNames.size());
for (String postProcessorName : nonOrderedPostProcessorNames) {
nonOrderedPostProcessors.add(beanFactory.getBean(postProcessorName, BeanFactoryPostProcessor.class));
}
invokeBeanFactoryPostProcessors(nonOrderedPostProcessors, beanFactory);
beanFactory.clearMetadataCache();
}
上面这个方法执行完后,已经完成了所有BeanFactoryPostProcessor的执行,也自然已经处理过所有的配置类了。
ConfigurationClassPostProcessor
在众多的后置处理器中,有一个独属于@Configuration
的后置处理器,就是ConfigurationClassPostProcessor
,一个好的命名的效果,就体现出来了。
下面这个方法,负责两件事
- 从
BeanDefinitionRegistry
中筛选出配置类 - 对配置类的
BeanDefinition
进行解析
// org.springframework.context.annotation.ConfigurationClassPostProcessor
public void processConfigBeanDefinitions(BeanDefinitionRegistry registry) {
// 候选配置类集合
List<BeanDefinitionHolder> configCandidates = new ArrayList<>();
// 获取所有的BeanDefinition的name数组
String[] candidateNames = registry.getBeanDefinitionNames();
for (String beanName : candidateNames) {
BeanDefinition beanDef = registry.getBeanDefinition(beanName);
// 如果BeanDefinition中有这个属性存在,说明作为一个配置类已经被处理过了
if (beanDef.getAttribute(ConfigurationClassUtils.CONFIGURATION_CLASS_ATTRIBUTE) != null) {
if (logger.isDebugEnabled()) {
logger.debug("Bean definition has already been processed as a configuration class: " + beanDef);
}
}
// 检查是否为一个配置类
// 查看是否具有@Configuration注解
// 这里不会仅仅看BeanDefinition所代表的类直接标注的注解,而是会递归查找其注解的注解是否有为
// @Configuration,只要找到了那么当前的类就是一个配置类
else if (ConfigurationClassUtils.checkConfigurationClassCandidate(beanDef, this.metadataReaderFactory)) {
configCandidates.add(new BeanDefinitionHolder(beanDef, beanName));
}
}
// 找不到就结束
if (configCandidates.isEmpty()) {
return;
}
// 对使用了@Order的进行排序 自然排序也就是升序
// 注意不是@Ordered
configCandidates.sort((bd1, bd2) -> {
int i1 = ConfigurationClassUtils.getOrder(bd1.getBeanDefinition());
int i2 = ConfigurationClassUtils.getOrder(bd2.getBeanDefinition());
return Integer.compare(i1, i2);
});
// 如果有自定义Bean Name生成器,就使用自定义的
SingletonBeanRegistry sbr = null;
if (registry instanceof SingletonBeanRegistry) {
sbr = (SingletonBeanRegistry) registry;
if (!this.localBeanNameGeneratorSet) {
BeanNameGenerator generator = (BeanNameGenerator) sbr.getSingleton(
AnnotationConfigUtils.CONFIGURATION_BEAN_NAME_GENERATOR);
if (generator != null) {
this.componentScanBeanNameGenerator = generator;
this.importBeanNameGenerator = generator;
}
}
}
// 如果还没有初始化Environment对象,初始化一个
if (this.environment == null) {
this.environment = new StandardEnvironment();
}
// 解析每一个被@Configuratin标注的注解类
ConfigurationClassParser parser = new ConfigurationClassParser(
this.metadataReaderFactory, this.problemReporter, this.environment,
this.resourceLoader, this.componentScanBeanNameGenerator, registry);
Set<BeanDefinitionHolder> candidates = new LinkedHashSet<>(configCandidates);
Set<ConfigurationClass> alreadyParsed = new HashSet<>(configCandidates.size());
do {
parser.parse(candidates);
parser.validate();
Set<ConfigurationClass> configClasses = new LinkedHashSet<>(parser.getConfigurationClasses());
configClasses.removeAll(alreadyParsed);
// 构造一个BeanDefinitionReader
if (this.reader == null) {
this.reader = new ConfigurationClassBeanDefinitionReader(
registry, this.sourceExtractor, this.resourceLoader, this.environment,
this.importBeanNameGenerator, parser.getImportRegistry());
}
// 加载配置类中的@Bean,生成BeanDefinition
this.reader.loadBeanDefinitions(configClasses);
alreadyParsed.addAll(configClasses);
candidates.clear();
// 下面这段主要是考虑到@Import进来的或者@ImportSource或者@Bean等方式注入进来的会有配置类
if (registry.getBeanDefinitionCount() > candidateNames.length) {
String[] newCandidateNames = registry.getBeanDefinitionNames();
Set<String> oldCandidateNames = new HashSet<>(Arrays.asList(candidateNames));
Set<String> alreadyParsedClasses = new HashSet<>();
for (ConfigurationClass configurationClass : alreadyParsed) {
alreadyParsedClasses.add(configurationClass.getMetadata().getClassName());
}
for (String candidateName : newCandidateNames) {
if (!oldCandidateNames.contains(candidateName)) {
BeanDefinition bd = registry.getBeanDefinition(candidateName);
if (ConfigurationClassUtils.checkConfigurationClassCandidate(bd, this.metadataReaderFactory) &&
!alreadyParsedClasses.contains(bd.getBeanClassName())) {
candidates.add(new BeanDefinitionHolder(bd, candidateName));
}
}
}
candidateNames = newCandidateNames;
}
}
while (!candidates.isEmpty());
//把 ImportRegistry注册成一个Bean,以便支持 继承ImportAware 有注解类@Configuration的配置类
if (sbr != null && !sbr.containsSingleton(IMPORT_REGISTRY_BEAN_NAME)) {
sbr.registerSingleton(IMPORT_REGISTRY_BEAN_NAME, parser.getImportRegistry());
}
}
这个方法执行完后,所有的配置类都会被进行处理,并且在此过程中,BeanDefinition
的总量有可能会增加,有新的BeanDefinition
在解析过程新增进来。
这些BeanDefinition
的来源就是存在于配置类上的其他注解
ConfigurationClassParser
SpringBoot
是如何使用一个@SpringBootApplication
注解,完成了那么多的事情?
答案就在下面揭晓
// `org.springframework.context.annotation.ConfigurationClassParser
protected final SourceClass doProcessConfigurationClass(
ConfigurationClass configClass, SourceClass sourceClass, Predicate<String> filter)
throws IOException {
// 如果有Component注解
if (configClass.getMetadata().isAnnotated(Component.class.getName())) {
// 首先递归处理内部类
processMemberClasses(configClass, sourceClass, filter);
}
// 处理所有的@PropertySource注解
for (AnnotationAttributes propertySource : AnnotationConfigUtils.attributesForRepeatable(
sourceClass.getMetadata(), PropertySources.class,
org.springframework.context.annotation.PropertySource.class)) {
if (this.environment instanceof ConfigurableEnvironment) {
processPropertySource(propertySource);
}
else {
logger.info("Ignoring @PropertySource annotation on [" + sourceClass.getMetadata().getClassName() +
"]. Reason: Environment must implement ConfigurableEnvironment");
}
}
// 处理所有的 @ComponentScan 和@ComponentScans
Set<AnnotationAttributes> componentScans = AnnotationConfigUtils.attributesForRepeatable(
sourceClass.getMetadata(), ComponentScans.class, ComponentScan.class);
if (!componentScans.isEmpty() &&
!this.conditionEvaluator.shouldSkip(sourceClass.getMetadata(), ConfigurationPhase.REGISTER_BEAN)) {
for (AnnotationAttributes componentScan : componentScans) {
// The config class is annotated with @ComponentScan -> perform the scan immediately
Set<BeanDefinitionHolder> scannedBeanDefinitions =
this.componentScanParser.parse(componentScan, sourceClass.getMetadata().getClassName());
// 继续检查扫描的BeanDefinition有没有是配置类的
for (BeanDefinitionHolder holder : scannedBeanDefinitions) {
BeanDefinition bdCand = holder.getBeanDefinition().getOriginatingBeanDefinition();
if (bdCand == null) {
bdCand = holder.getBeanDefinition();
}
if (ConfigurationClassUtils.checkConfigurationClassCandidate(bdCand, this.metadataReaderFactory)) {
// 如果是的话,解析
parse(bdCand.getBeanClassName(), holder.getBeanName());
}
}
}
}
// 处理所有的@Import注解,将导入的Bean注册到BeanDefinitionRegistry
// 会递归查找出所有的@Import
// getImports会查找所有配置类上的@Import注解,@Import可以导入一个普通的配置类
// 也可以是ImportSelector或者ImportBeanDefinitionRegistrar的实现类
// 之所以需要ImportSelector和ImportBeanDefinitionRegistrar,是为了可以更加方便的一次注册多个类
// 这俩接口的实现类,也一要由Import导入进来,或者直接使用@Component,不过这样就就没必要去实现接口了
// 这三个的主要用途不是为了注册自己程序中的类成为一个Bean,而是为了那些不方便使用@Component注解的类
// @Component的更像一个为了业务代码使用的注解
processImports(configClass, sourceClass, getImports(sourceClass), filter, true);
// 处理所有的@ImportResource 注解,将导入的Bean注册到BeanDefinitionRegistry
AnnotationAttributes importResource =
AnnotationConfigUtils.attributesFor(sourceClass.getMetadata(), ImportResource.class);
if (importResource != null) {
String[] resources = importResource.getStringArray("locations");
Class<? extends BeanDefinitionReader> readerClass = importResource.getClass("reader");
for (String resource : resources) {
String resolvedResource = this.environment.resolveRequiredPlaceholders(resource);
configClass.addImportedResource(resolvedResource, readerClass);
}
}
// 处理独立的 @Bean方法,生成BeanMethod
// 使用@Bean,方法要是可重写,也就是不能为default/private,因为要使用CGLIB代理
// 详细可进去下面方法细看
Set<MethodMetadata> beanMethods = retrieveBeanMethodMetadata(sourceClass);
for (MethodMetadata methodMetadata : beanMethods) {
configClass.addBeanMethod(new BeanMethod(methodMetadata, configClass));
}
// 处理接口的默认方法
processInterfaces(configClass, sourceClass);
// 如果有父类,处理
if (sourceClass.getMetadata().hasSuperClass()) {
String superclass = sourceClass.getMetadata().getSuperClassName();
if (superclass != null && !superclass.startsWith("java") &&
!this.knownSuperclasses.containsKey(superclass)) {
this.knownSuperclasses.put(superclass, configClass);
// Superclass found, return its annotation metadata and recurse
return sourceClass.getSuperClass();
}
}
//没有父类,处理完成
return null;
}
看下@SpringBootApplication
的定义
@Target(ElementType.TYPE)
@Retention(RetentionPolicy.RUNTIME)
@Documented
@Configuration
public @interface SpringBootConfiguration {
}
@Target(ElementType.TYPE)
@Retention(RetentionPolicy.RUNTIME)
@Documented
@Inherited
@SpringBootConfiguration
@EnableAutoConfiguration
@ComponentScan(excludeFilters = { @Filter(type = FilterType.CUSTOM, classes = TypeExcludeFilter.class),
@Filter(type = FilterType.CUSTOM, classes = AutoConfigurationExcludeFilter.class) })
public @interface SpringBootApplication {
}
可以看到@SpringBootApplication
在功能上也是一个@Configuration
。
这样就解释了,一般在SpringBoot
的启动类上写了那么多注解,为啥可以被执行。
如果有看过各类@Enable
注解,就一定会看到,每一个@Enable
几乎都会被@Import
所注解,而一般使用@Enable
时,都会和@SpringBootApplication
写一起,这个写法的一方面是比较清晰,集中写到一起,还有个原因就是部分@Enable
在定义时,没有使用@Configuration
来进行注解,需要借助于一个能被Spring容器启动时处理的配置类上。
上面的这段代码分析,正好解释了@Enable
背后的实现原理。
总结
其实总的看下来,@Configuration
就是一个标志注解,更大的作用就是为别的注解服务的。这么说有点矛盾,主要是觉得本身不具备什么功能性。
至于其能实现的对字段进行配置值绑定来说,可以使用@ConfigurationProperties
或者@Value
这两个注解来实现,由此可见,@Configuration
并不是用于将配置文件的配置值,绑定到配置类的,这个工作和他没有任何关系,对于一些配置文件的配置来说,可以使用@Component
注解来对普通的配置类注解,达到一样的效果,而并非一定要使用@Configuration
(@Configuration
注解派生自@Component
)。
通过我们上面的分析,被@Configuration
注解的类,仅有存在以上那几个注解时,才有意义,才能被ConfigurationClassPostProcessor
所处理,而这个处理过程中,和配置值绑定一毛钱的关系都没有。
实际上配置值的绑定,都是在Bean
实例化后,Bean
属性填充期间进行的。
@ConfigurationProperties
注解会在ConfigurationPropertiesBindingPostProcessor
执行时进行处理,这个处理器是一个BeanPostProcessor
。
@Value
注解的处理是在AutowiredAnnotationBeanPostProcessor
这个BeanPostProcessor
中来处理的,这个处理器同时也是处理@Inject
、 @Autowired
、 @Resource
的BeanPostProcesoor
。
Spring
或者SpringBoot
中,大量的使用各种后置处理器,除了对主体框架(Bean
的生命周期)的理解外,剩下的主要就是熟悉这些支持各种功能的PostProcessor
。
还有个值得注意的是,@Configuration
有个方法proxyBeanMethods
,这个方法返回true
时,默认也是true
,会对我们的配置类,生成一个代理类,注意,这里是直接生成一个代理类,并且最后实例化时,也是使用这个代理类进行实例化Bean
,这个就给我们一个启发,如果想对一些无法直接修改又被Spring
容器所管理的的Bean
,是否可以通过自定义BeanDefinitionRegistryPostProcessor
的方式,来对原Class
做一个增强,从而实现我们的目的。
PS:是否具备切实可行性,并不保证,只是觉得如果遇到,可以尝试下。
Spring处理@Configuration的分析的更多相关文章
- Spring Security 源码分析(四):Spring Social实现微信社交登录
社交登录又称作社会化登录(Social Login),是指网站的用户可以使用腾讯QQ.人人网.开心网.新浪微博.搜狐微博.腾讯微博.淘宝.豆瓣.MSN.Google等社会化媒体账号登录该网站. 前言 ...
- spring AOP源码分析(三)
在上一篇文章 spring AOP源码分析(二)中,我们已经知道如何生成一个代理对象了,那么当代理对象调用代理方法时,增强行为也就是拦截器是如何发挥作用的呢?接下来我们将介绍JDK动态代理和cglib ...
- Spring Boot 入门详细分析
推荐阅读: 我们为什么要学习 Spring Boot 我们搭建 Spring Boot 项目,可以使用 Spring 为我们提供的初始化网站,那个可能不太方便,今天呢,我们就来说说如何使用 IDEA ...
- Spring注解 @Configuration
Spring注解 @Configuration 一.@Configuration的作用 二.@Configuration的Spring容器启动方式 三.不加@Configuration的@Bean的解 ...
- Spring IOC 源码分析
Spring 最重要的概念是 IOC 和 AOP,本篇文章其实就是要带领大家来分析下 Spring 的 IOC 容器.既然大家平时都要用到 Spring,怎么可以不好好了解 Spring 呢?阅读本文 ...
- Spring MVC源码分析(三):SpringMVC的HandlerMapping和HandlerAdapter的体系结构设计与实现
概述在我的上一篇文章:Spring源码分析(三):DispatcherServlet的设计与实现中提到,DispatcherServlet在接收到客户端请求时,会遍历DispatcherServlet ...
- Spring IoC 源码分析 (基于注解) 之 包扫描
在上篇文章Spring IoC 源码分析 (基于注解) 一我们分析到,我们通过AnnotationConfigApplicationContext类传入一个包路径启动Spring之后,会首先初始化包扫 ...
- Spring Security 源码分析 --- WebSecurity
概述 spring security 源码分析系列文章. 源码分析 我们想一下,我们使用 ss 框架的步骤是怎么样的. @Configuration @EnableWebSecurity @Enabl ...
- 精尽Spring MVC源码分析 - 寻找遗失的 web.xml
该系列文档是本人在学习 Spring MVC 的源码过程中总结下来的,可能对读者不太友好,请结合我的源码注释 Spring MVC 源码分析 GitHub 地址 进行阅读 Spring 版本:5.2. ...
随机推荐
- System.Timers.Timer
前言 System.Timers.Timer组件是基于服务器的计时器,它能够指定在应用程序中引发Elapsed事件周期性间隔,以处理相应事件. 使用示例: 运行结果展示: System.Timers. ...
- 通达OA-2017版本漏洞复现
搭建环境 服务器 虚拟机系统版本:Windows Server 2016. 安装服务端 1.下载安装程序 这里我们下载的是2017版本的通达OA服务端: 2.安装程序 配置服务: 漏洞复现 1.任意文 ...
- (第九篇)Iptables详解
常见的网络攻击形式 1.拒绝服务攻击:DOS 2.分布式拒绝服务攻击 DDOS 3.漏洞入侵 4.口令猜测 以上内容简单了解,具体可自行百度,此处不必知晓. Linux防火墙基础 Linux防火墙体系 ...
- QMessage自动定时关闭
QMessageBox *box = new QMessageBox(QMessageBox::Information,tr("test"),tr("testtest&q ...
- MinIO 的分布式部署
目录 1 前言 2 分布式存储可靠性常用方法 2.1 冗余 2.2 校验 3 MinIO存储机制 3.1 概念理解 3.2 纠删码EC(Erasure Code) 3.3 存储形式 4 部署实践 4. ...
- 【JAVA基础】04 Java语言基础:方法
1. 方法概述和格式说明 为什么要有方法 提高代码的复用性 什么是方法 完成特定功能的代码块. 方法的格式 修饰符 返回值类型 方法名(参数类型 参数名1,参数类型 参数名2...) { 方法 ...
- apache、nginx配置自签名证书
一.apache: 安装apache.ssl.openssl yum -y install httpd httpd-pear mod_ssl openssl 生成证书文件 openssl genrsa ...
- 关于Python的JSON
1.json模块load/loads.dump/dumps区别:(摘自这里) 实际上json就是python字典的字符串表示,但是字典作为一个复杂对象是无法直接转换成定义它的代码的字符串,python ...
- Codeforce 1255 Round #601 (Div. 2) A. Changing Volume (贪心)
Bob watches TV every day. He always sets the volume of his TV to bb. However, today he is angry to f ...
- 图论--最短路-- Dijkstra模板(目前见到的最好用的)
之前的我那个板子,老是卡内存,不知道为什么,我看别人过的那个题都是结构体,我就开始对自己板子做了修改,然后他奶奶的就过了,而且速度也提高了,内存也小了.(自从用了这个板子,隔壁小孩馋哭了)也不知道为啥 ...