Spring處理@Configuration的分析
Spring處理@Configuration的分析
聲明：本文如有任何紕漏、錯誤，還請不吝指出！java
序言
@Configuration註解在SpringBoot中做用很大，且不說SpringBoot中的外部化配置，一些第三方組件也是經過這個註解完成整合的，經常使用的好比說mybatis，就是利用了@Configuration這個註解來實現的。spring
在註解類中，還可使用@Bean的方式向Spring容器中，注入一些咱們自定義的組件。數組
在SpringBoot中各類Enable又是如何實現的？和@Configuration又有什麼聯繫呢？mybatis
這就要了解Spring是怎麼對待被@Configuration所註解的類。框架
環境
SpringBoot 2.2.6RELEASEpost
Spring 5.2.5.RELEASEui
正文
註解依附於具體的Java類，因此若是想獲取註解的信息，必須先將類加載進來，才能從Class對象獲取到其註解元信息。this
好在Spring容器啓動以前，已經把全部須要加載的Bean，封裝成一個BeanDefinition對象，最終註冊到BeanDefinitionRegistry中。lua
BeanDefinition包含了一個Bean全部的信息，天然也包含了它的元註解信息。spa
有了這個就能垂手可得的獲取到標註有@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：是否具有切實可行性，並不保證，只是以爲若是遇到，能夠嘗試下。
相關文章
- 1. Spring源碼分析之@Configuration的處理
- 2. 【小家Spring】Spring解析@Configuration註解的處理器：ConfigurationClassPostProcessor（ConfigurationClassParser）
- 3. Spring component-scan源碼分析（二） -- @Configuration註解處理
- 4. Spring中Configuration的理解
- 5. Spring MVC請求處理流程分析
- 6. mybatis-spring事務處理機制分析
- 7. Spring源碼解析之@Configuration
- 8. Spring之@Configuration配置解析
- 9. spring的configuration
- 10. Spring Configuration Check Unmapped Spring configuration files found.Please configure Spring
- 更多相關文章...
- • 錯誤處理 - RUST 教程
- • C# 異常處理 - C#教程
- • 互聯網組織的未來：剖析GitHub員工的任性之源
- • 常用的分佈式事務解決方案
相關標籤/搜索
每日一句
-
每一个你不满意的现在，都有一个你没有努力的曾经。
歡迎關注本站公眾號,獲取更多信息
相關文章
- 1. Spring源碼分析之@Configuration的處理
- 2. 【小家Spring】Spring解析@Configuration註解的處理器：ConfigurationClassPostProcessor（ConfigurationClassParser）
- 3. Spring component-scan源碼分析（二） -- @Configuration註解處理
- 4. Spring中Configuration的理解
- 5. Spring MVC請求處理流程分析
- 6. mybatis-spring事務處理機制分析
- 7. Spring源碼解析之@Configuration
- 8. Spring之@Configuration配置解析
- 9. spring的configuration
- 10. Spring Configuration Check Unmapped Spring configuration files found.Please configure Spring