遇到一個問題，報上來一個app加入一個lib，啟動就突然失敗了。報了一個Autowire錯誤 NullPointerException。但是奇怪的是，大部分其他的App 加入這個library 之后都風平浪靜，一切正常。那么這個app有何特殊之處？
首先要解決這個NullPointerException 為何會出現. 這個出錯的是個AutoConfiguration 類
package io.http.env.client;
@Configuration
@AutoConfigureAfter(name = { "com.metadata.MetadataInitializer"})
public class HttpEnvInitializer {
@Autowired
public HttpEnvInitializer(SpellFasterServiceClient client){
client.call()
....
}
}
spring.factories 的配置類似
org.springframework.boot.autoconfigure.EnableAutoConfiguration=\
io.montage.env.client.HttpEnvInitializer
這個SpellCasterServiceClient 的bean 應該出現在這個AutoConfig 里
package io.montage.env.client;
@AutoConfigureBefore(name = { "com.metadata.MetadataInitializer" })
public class MFClientInitializer {
@Bean
public SpellFasterServiceClient getSpellFasterServiceClient() {
return SpellFasterServiceClientBuilder.target().build();
}
spring.factories 的配置類似
org.springframework.boot.autoconfigure.EnableAutoConfiguration=\
io.montage.env.client.SpellFasterServiceClient
這就是不科學了，構造SpellFasterServiceClient 的順序在com.metadata.MetadataInitializer 之前，注入句柄的是在com.metadata.MetadataInitializer之后，這看起完全沒有問題。
從程序看來，這個運行順序完全沒有問題
MFClientInitializer ->MetadataInitializer->HttpEnvInitializer
但是實際呢,通過debug 可以看到順序是這樣的
HttpEnvInitializer->MFClientInitializer ->MetadataInitializer
這就奇怪了，為啥AutoConfig 的before 和after 這些annotation 不起作用了？
需要看看什么導致了順序變化，發現有人在Application 類新加了一個@ComponentScan("io.montage.env")，這下恍然大悟。原來和library 添加無關。
@SpringBootApplication
@EnableAsync
@ComponentScan("io.montage.env")
@Import({WebSpringConfig.class})
public class MonitorManagerApplication {
public static void main(String[] args) {
SpringApplication.run(MonitorManagerApplication.class, args);
}
}
這個@ComponentScan("io.montage.env") 純屬畫蛇添足。這也解釋了為什么只有這個App有問題，而其他的沒問題。
下面就要談談Configuration和AutoConfiguration的區別
Configuration和AutoConfiguration
他們都是定義Bean 的一種方式。
相同點：
- 他們都用@Configuration 做annotation. 他們同樣都可以加 @Bean、@Import、@ImportResource.
- 他們都可以用 @Condition 來控制加載條件.
不同點：
目的：
- @Configuration 是給Application 的用戶，直接代碼進行配置的。
- AutoConfiguration 是給 Springboot 插件俗稱starter用的。
加載的方式:
- @Configuration 加載是由@ComponentScan指定的package，如果沒有指定，default 是ApplicationClass 的package 開始。
- AutoConfiguration 是通過 classpath*:META-INF/spring.factories 來被發現。 通過 key org.springframework.boot.autoconfigure.EnableAutoConfiguration. AutoConfiguration 是由 import selector 的方式加載的, 而不是 scan path.
- 順序：正常情況下, @Configuration 先加載 AutoConfiguration后加載。
請看class ConfigurationClassParser#doProcessConfigurationClass
class ConfigurationClassParser {
protected final SourceClass doProcessConfigurationClass(
ConfigurationClass configClass, SourceClass sourceClass, Predicate<String> filter)
throws IOException {
if (configClass.getMetadata().isAnnotated(Component.class.getName())) {
// Recursively process any member (nested) classes first
processMemberClasses(configClass, sourceClass, filter);
}
// Process any @PropertySource annotations
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");
}
}
// Process any @ComponentScan annotations
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());
// Check the set of scanned definitions for any further config classes and parse recursively if needed
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());
}
}
}
}
// Process any @Import annotations
processImports(configClass, sourceClass, getImports(sourceClass), filter, true);
// Process any @ImportResource annotations
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);
}
}
// Process individual @Bean methods
Set<MethodMetadata> beanMethods = retrieveBeanMethodMetadata(sourceClass);
for (MethodMetadata methodMetadata : beanMethods) {
configClass.addBeanMethod(new BeanMethod(methodMetadata, configClass));
}
// Process default methods on interfaces
processInterfaces(configClass, sourceClass);
// Process superclass, if any
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();
}
}
// No superclass -> processing is complete
return null;
}
}
, 先運行下面代碼來加載@Configuration
Set<AnnotationAttributes> componentScans = AnnotationConfigUtils.attributesForRepeatable(
sourceClass.getMetadata(), ComponentScans.class, ComponentScan.class);
然后在運行
processImports(configClass, sourceClass, getImports(sourceClass), filter, true);
而EnableAutoConfiguration 定義了AutoConfigurationImportSelector，來load 所有的AutoConfig
@Target(ElementType.TYPE)
@Retention(RetentionPolicy.RUNTIME)
@Documented
@Inherited
@AutoConfigurationPackage
@Import(AutoConfigurationImportSelector.class)
public @interface EnableAutoConfiguration {
}
有正常就有不正常的情況，看看什么情況下不正常。
異常情況：
AutoConfiguration 可以使用@AutoConfigureOrder 或者 @AutoConfigureBefore、@AutoConfigureAfter
但是下面情況 AutoConfiguration 會破壞順序，以@Configuraiton 被加載：
- AutoConfiguration的class 也在 scan path（@ComponentScan) ，所以他就被認為既是Configuration，又是AutoConfiguration。所以會被加載兩次。 當以Configuration身份時先被加載。 因此 @AutoConfigureBefore and @AutoConfigureAfter 就不起作用了。
- AutoConfiguration定義了 BeanPostProcessor。請看BeanPostProcessorAutoConfiguration的邏輯.
- AutoConfiguration 使用了 ImportBeanDefinitionRegistrar。
- AutoConfiguration 使用 ImportSelector。
請參考AutoConfigurationImportSelector AutoConfigurationImportSelector了解更多細節.
在前面的問題中， 就是由于io.montage.env 在scan path里，因此 @AutoConfigureBefore and @AutoConfigureAfter 不起作用了。
@SpringBootApplication
@EnableAsync
@ComponentScan("io.montage.env")
@Import({WebSpringConfig.class})
public class MonitorManagerApplication {
public static void main(String[] args) {
SpringApplication.run(MonitorManagerApplication.class, args);
}
}
如何判斷初始化順序不正常：
當然加載順序沒有按照預定設想順序，是比較難以排查的。介紹大家一個簡單的方法。
appContext.getBeanDefinitionNames 中找到相關的bean name，以上圖為例，如果是spring.factories 中定義的名字 例如io.montage.env.client.HttpEnvInitializer， 那么就是從AutoConfiguration 拿來的，如果是httpEnvInitializer, 這種就是從scan path 里掃描出來的。這樣很容易就可以看到到底是怎么被load進來的。
