文章目錄
上一篇我們講了默認標籤-
bean標籤的解析，今天我們講一下自定義標籤的解析。
一、自定義標籤是什麼？
1. 自定義標籤的定義
這個問題其實上一篇有講過，這邊再複述一遍，在spring的xml配置文件中，我們可以把所有的標籤分爲兩類：自定義標籤和默認標籤，區別如下
<!-- 標籤前面有 xxx:即是spring的自定義標籤，我們也可以自己定義一個xiaozize:的標籤-之後會講到 -->
<context:component-scan base-package="com.xiaoxizi.spring"/>
<!-- 該標籤對應的命名空間在xml文件頭部beans標籤中聲明 -->
<beans xmlns:context="http://www.springframework.org/schema/context" ... />
<!-- 默認標籤沒有 xx: 前綴 -->
<bean class="com.xiaoxizi.spring.service.AccountServiceImpl"
id="accountService" scope="singleton" primary="true"/>
<!-- 對應的命名空間也在xml文件頭部beans標籤中聲明 -->
<beans xmlns="http://www.springframework.org/schema/beans" ... />
需要注意的是，自定義標籤的概念，並不完全只指我們開發時自己定義的標籤，而是spring的開發者爲之後拓展預留的拓展點，這個拓展點我們可以用，spring的開發人員在爲spring添加新功能時，也可以使用。
2. 關於spring內置的自定義標籤context:component-scan
我們現在的開發中，更多的情況下，其實是使用@Configuration、@Component、@Service 等註解來進行bean的聲明而不是使用xml的bean 標籤了。
那麼爲什麼一個類加上了這些註解之後，就能被spring管理了呢？
實際上這些拓展功能是spring通過自己預留的自定義標籤的拓展點進行拓展的，對於上述的功能，具體是使用的context:component-scan標籤。
我們今天就通過對自定義標籤context:component-scan的解析來跟蹤一下相應的源碼，理解spring自定義標籤解析的流程，同時也對context:component-scan實現的功能做一個講解，看一下@Component等標籤的實現原理。
二、源碼解析
1. 自定義標籤解析過程
由於上一篇對xml的源碼跟過了，這期我們之間定位到相應代碼org.springframework.beans.factory.xml.DefaultBeanDefinitionDocumentReader#parseBeanDefinitions
protected void parseBeanDefinitions(Element root, BeanDefinitionParserDelegate delegate) {
// 判斷是否是默認的命名空間
if (delegate.isDefaultNamespace(root)) {
NodeList nl = root.getChildNodes();
for (int i = 0; i < nl.getLength(); i++) {
Node node = nl.item(i);
if (node instanceof Element) {
Element ele = (Element) node;
if (delegate.isDefaultNamespace(ele)) {
// 解析默認標籤
parseDefaultElement(ele, delegate);
}
else {
// 可以看到代理主要進行自定義標籤的解析
delegate.parseCustomElement(ele);
}
}
}
}
else {
// 可以看到代理主要進行自定義標籤的解析
delegate.parseCustomElement(root);
}
}
@Nullable
public BeanDefinition parseCustomElement(Element ele, @Nullable BeanDefinition containingBd) {
// 獲取標籤對於的namespaceUrl, 即配置文件頭部beans標籤裏面那些xmlns:xxx=www.xxx.com
String namespaceUri = getNamespaceURI(ele);
if (namespaceUri == null) {
return null;
}
// 獲取自定義標籤對應的NamespaceHandler，從這裏我們可以看到，對於每一個namespaceUri應該都有唯一一個對應的NamespaceHandler
NamespaceHandler handler = this.readerContext.getNamespaceHandlerResolver().resolve(namespaceUri);
if (handler == null) {
error("Unable to locate Spring NamespaceHandler for XML schema namespace [" + namespaceUri + "]", ele);
return null;
}
// 把自定義標籤委託給對應的NamespaceHandler解析
return handler.parse(ele, new ParserContext(this.readerContext, this, containingBd));
}
我們先看一下NamespaceHandler這個自定義標籤的解析接口的結構：
public interface NamespaceHandler {
// 初始化，我們可以合理猜測，這個方法將會在NamespaceHandler實例化之後，使用之前調用
void init();
// xml解析入口
@Nullable
BeanDefinition parse(Element element, ParserContext parserContext);
// 裝飾接口，其實用的比較少，上一篇有稍微帶到過一下，默認bean標籤解析完之後，可以有一個機會對解析出來的beanDefinition進行裝飾，實際開發中很少使用
// 有興趣的同學可以自行看下源碼，源碼在 org.springframework.beans.factory.xml.DefaultBeanDefinitionDocumentReader#processBeanDefinition
@Nullable
BeanDefinitionHolder decorate(Node source, BeanDefinitionHolder definition, ParserContext parserContext);
}
接下來當然是需要看一下獲取NamespaceHandler的流程：
public NamespaceHandler resolve(String namespaceUri) {
// 獲取到了一個handlerMapping，具體邏輯我們之後再看
Map<String, Object> handlerMappings = getHandlerMappings();
// 通過namespaceUri獲取到一個對象
Object handlerOrClassName = handlerMappings.get(namespaceUri);
if (handlerOrClassName == null) {
return null;
}
// 如果handlerOrClassName是一個NamespaceHandler對象，則直接返回 - 拿到對應的handler了
else if (handlerOrClassName instanceof NamespaceHandler) {
return (NamespaceHandler) handlerOrClassName;
}
else {
// 如果handlerOrClassName不是NamespaceHandler對象，則是String對象
String className = (String) handlerOrClassName;
// 通過String獲取到一個Class對象，那麼這個String對象肯定是一個類的全限定名啦
Class<?> handlerClass = ClassUtils.forName(className, this.classLoader);
// handlerClass必須繼承自NamespaceHandler，很好理解，畢竟是spring提供的拓展點，自然需要符合它定義的規則
if (!NamespaceHandler.class.isAssignableFrom(handlerClass)) {
throw new FatalBeanException("...");
}
// 直接通過反射構造一個實例，點進去看會發現是調用的無參構造器，我們就不看了
NamespaceHandler namespaceHandler = (NamespaceHandler) BeanUtils.instantiateClass(handlerClass);
// !!! 調用了init()方法，和我們之前的推測一致
namespaceHandler.init();
// !!! 把handler對象塞回了handlerMappings，所以我們下次再通過namespaceUri獲取時，會直接拿到一個NamespaceHandler對象
// 也即每個namespaceUri對應的NamespaceHandler對象是單例的，而init()方法也只會調用一次
handlerMappings.put(namespaceUri, namespaceHandler);
return namespaceHandler;
// 去除掉了異常處理
}
}
由上述源碼其實我們已經得知了NamespaceHandler的一個初始化過程，但其實還有一個疑問，就是這個handlerMappings中最初的那些namespaceUri對應的handler的類名是哪來的呢？這個時候我們就需要去看一下getHandlerMappings()的過程啦
private Map<String, Object> getHandlerMappings() {
Map<String, Object> handlerMappings = this.handlerMappings;
if (handlerMappings == null) {
synchronized (this) {
handlerMappings = this.handlerMappings;
// 雙重檢查加鎖，看來我們的handlerMappings之後加載一次
if (handlerMappings == null) {
// 可以看到這邊是去加載了文件
// 文件加載的過程我們就不去跟了，跟主流程關係不大，我們主要看一下這個文件位置
// this.handlerMappingsLocation是哪裏
Properties mappings =
PropertiesLoaderUtils.loadAllProperties(this.handlerMappingsLocation, this.classLoader);
handlerMappings = new ConcurrentHashMap<>(mappings.size());
// 然後把文件中的kev-value屬性都合併到了一個map裏
CollectionUtils.mergePropertiesIntoMap(mappings, handlerMappings);
this.handlerMappings = handlerMappings;
// 幹掉了異常處理代碼
}
}
}
return handlerMappings;
}
// 字段的定義， 需要說一下當前類是DefaultNamespaceHandlerResolver，喜歡自己探索的同學可以直接空降
/** Resource location to search for. */
private final String handlerMappingsLocation;
// 可以看到這個值是Resolver的構造器中設值的
public DefaultNamespaceHandlerResolver(@Nullable ClassLoader classLoader, String handlerMappingsLocation) {
this.classLoader = (classLoader != null ? classLoader : ClassUtils.getDefaultClassLoader());
this.handlerMappingsLocation = handlerMappingsLocation;
}
// 默認是取的DEFAULT_HANDLER_MAPPINGS_LOCATION這個常量
public DefaultNamespaceHandlerResolver() {
this(null, DEFAULT_HANDLER_MAPPINGS_LOCATION);
}
// 我們看一下這個常量的值
public static final String DEFAULT_HANDLER_MAPPINGS_LOCATION = "META-INF/spring.handlers";
如果對SPI比較熟悉的同學，應該已經知道這是個什麼套路了，並且對META-INF這個目錄也比較熟悉，那麼現在，我們看一下這個META-INF/spring.handlers文件中到底寫了一些什麼東西，以context:component-scan標籤爲例，我們知道這個標籤是spring-context包裏面提供的，直接去找這個jar包的對應文件，看一下里面的內容：
## 我們可以很明顯的看到一個key=value結構
http\://www.springframework.org/schema/context=org.springframework.context.config.ContextNamespaceHandler
http\://www.springframework.org/schema/jee=org.springframework.ejb.config.JeeNamespaceHandler
http\://www.springframework.org/schema/lang=org.springframework.scripting.config.LangNamespaceHandler
http\://www.springframework.org/schema/task=org.springframework.scheduling.config.TaskNamespaceHandler
http\://www.springframework.org/schema/cache=org.springframework.cache.config.CacheNamespaceHandler
我們在回憶一下自定義標籤的定義：
<!-- 標籤前面有 xxx:即是spring的自定義標籤，我們也可以自己定義一個xiaozize:的標籤-之後會講到 -->
<context:component-scan base-package="com.xiaoxizi.spring"/>
<!-- 該標籤對應的命名空間在xml文件頭部beans標籤中聲明 -->
<beans xmlns:context="http://www.springframework.org/schema/context" ... />
可以看到我們的META-INF/spring.handlers文件中key就是自定義標籤的namespaceUri，value則是對應的NamespaceHandler的全限定名。
那麼簡單總結一下，我們的自定義標籤解析的流程就是：
-
加載所有jar中
META-INF/spring.handlers文件中的namespaceUri和NamespaceHandler的全限定名的映射關係到handlerMappings -
根據
namespaceUri從handlerMappings獲取對象-
如果從
handlerMappings獲取到的對象爲空，直接返回 -
如果獲取到的是
NamespaceHandler對象，直接使用 -
如果獲取到的對象是string類型，則實例化這個string對應的全限定名的
NamespaceHandler對象，並調用init()方法，然後將namespaceUri-NamespaceHandler對象關係放回handlerMappings
-
-
將自定義標籤委託給2獲取到的
NamespaceHandler對象解析-調用parse方法（如果2未獲取到對應的NamespaceHandler對象，則此自定義標籤無法解析，直接跳過）
2. context:component-scan標籤工作原理
接下來我們來看一下 context:component-scan標籤的工作原理，從spring-context包的META-INF/spring.handlers文件我們可以找到該標籤對應的處理器：
http\://www.springframework.org/schema/context=org.springframework.context.config.ContextNamespaceHandler
直接找到這個類：
public class ContextNamespaceHandler extends NamespaceHandlerSupport {
@Override
public void init() {
// 刪掉了一些我們不關注的標籤的Parser的注入代碼...
// 我們可以看到這裏註冊了一個BeanDefinitionParser，而且這個註冊方法的第一個參數明顯是
// `context:component-scan` 標籤中刪掉前綴的部分，我們先記下來
registerBeanDefinitionParser("component-scan", new ComponentScanBeanDefinitionParser());
// 刪掉了一些我們不關注的標籤的Parser的注入代碼...
}
}
可以看到ContextNamespaceHandler繼承自NamespaceHandlerSupport，這是一個典型的模本方法設計模式。這裏不做拓展，我們直接看一下NamespaceHandlerSupport：
// 這裏我們只保存了與解析器相關的代碼，並且調整了一下源碼順序
// 裝飾相關的代碼我去除掉了，並不是NamespaceHandlerSupport中沒有，不過它的邏輯和解析基本是一致的
// 如果同學們還記得哪裏對beanDefinition進行了裝飾，並且感興趣的話，可以自行了解一下 (*￣︶￣)
public abstract class NamespaceHandlerSupport implements NamespaceHandler {
// 保存標籤名-解析器對應關係的容器
private final Map<String, BeanDefinitionParser> parsers = new HashMap<>();
// 保存標籤名-裝飾器對應關係的容器
private final Map<String, BeanDefinitionDecorator> decorators = new HashMap<>();
// 保存屬性名-裝飾器對應關係的容器
private final Map<String, BeanDefinitionDecorator> attributeDecorators = new HashMap<>();
// 可以看到我們init()方法中的register其實就只是把對應elementName-Parser放入map而已
protected final void registerBeanDefinitionParser(String elementName, BeanDefinitionParser parser) {
this.parsers.put(elementName, parser);
}
public BeanDefinition parse(Element element, ParserContext parserContext) {
// 獲取 Parser
BeanDefinitionParser parser = findParserForElement(element, parserContext);
// 委託給 Parser解析
return (parser != null ? parser.parse(element, parserContext) : null);
}
private BeanDefinitionParser findParserForElement(Element element, ParserContext parserContext) {
// 這裏是獲取了去掉標籤中去掉前綴後的名稱 context:component-scan --> component-scan
String localName = parserContext.getDelegate().getLocalName(element);
// 從map中獲取到對應的Parser
return this.parsers.get(localName);
}
}
到此爲止其實還是蠻簡單的嘛，我們又把標籤委託給了對應的Parser來處理，那麼我們現在來看一下component-scan對應的ComponentScanBeanDefinitionParser的邏輯，我們先看parse方法，也是我們的入口方法：
public BeanDefinition parse(Element element, ParserContext parserContext) {
// 獲取標籤上配置並處理的base-package屬性
String basePackage = element.getAttribute(BASE_PACKAGE_ATTRIBUTE);
// 處理佔位符
basePackage = parserContext.getReaderContext().getEnvironment().resolvePlaceholders(basePackage);
// 最終獲取到的是一個數組 - 因爲我們配置的時候是可以配置多個的
String[] basePackages = StringUtils.tokenizeToStringArray(basePackage,
ConfigurableApplicationContext.CONFIG_LOCATION_DELIMITERS);
// 獲取一個掃描器 - 這個東西很重要，我們以後還會看到
ClassPathBeanDefinitionScanner scanner = configureScanner(parserContext, element);
// 嗯，掃描器進行掃描，看來就是這個方法會掃描那些註解了
Set<BeanDefinitionHolder> beanDefinitions = scanner.doScan(basePackages);
// 註冊一些組件
registerComponents(parserContext.getReaderContext(), beanDefinitions, element);
return null;
}
我們先看一下掃描器是怎麼創建出來的：
// 把一些異常處理都幹掉了
protected ClassPathBeanDefinitionScanner configureScanner(ParserContext parserContext, Element element) {
// 解析一下是否用默認的過濾器 --> 這裏解釋一下，其實這個過濾器就是指我們那些註解@Service等。
// 其實這裏就是定義那些註解是我們掃描到了之後會把它納入IOC管理的，具體代碼之後解析的時候會看到
boolean useDefaultFilters = true;
if (element.hasAttribute(USE_DEFAULT_FILTERS_ATTRIBUTE)) {
useDefaultFilters = Boolean.parseBoolean(element.getAttribute(USE_DEFAULT_FILTERS_ATTRIBUTE));
}
// 直接創建一個掃描器
ClassPathBeanDefinitionScanner scanner = createScanner(parserContext.getReaderContext(), useDefaultFilters);
// 從parserContext獲取到的默認的beanDefinition的配置，即之後解析的beanDefinition的缺省配置
scanner.setBeanDefinitionDefaults(parserContext.getDelegate().getBeanDefinitionDefaults());
// 從parserContext獲取到的默認的自動裝配的模式，byType、byName那些
scanner.setAutowireCandidatePatterns(parserContext.getDelegate().getAutowireCandidatePatterns());
// 掃描的資源路徑，一般我們也不配置
if (element.hasAttribute(RESOURCE_PATTERN_ATTRIBUTE)) {
scanner.setResourcePattern(element.getAttribute(RESOURCE_PATTERN_ATTRIBUTE));
}
// 沒什麼用的...一般也不會去自定義，即使用註解時，生成bean的name的策略也可以自定義
parseBeanNameGenerator(element, scanner);
// 基本也不用，scope相關的，大概意思就是這個bean會存在於哪些scope，一般不用
parseScope(element, scanner);
// 解析類型過濾器-這個算相對重要，其實就是我們可以自定義需要掃描哪些註解
parseTypeFilters(element, scanner, parserContext);
return scanner;
}
我們先看一下如果useDefaultFilters=true會註冊哪些過濾器，createScanner中其實就是直接調用了構造器，那我們直接看一下構造器邏輯：
public ClassPathBeanDefinitionScanner(BeanDefinitionRegistry registry,
boolean useDefaultFilters,
Environment environment,
@Nullable ResourceLoader resourceLoader) {
Assert.notNull(registry, "BeanDefinitionRegistry must not be null");
this.registry = registry;
if (useDefaultFilters) {
// 註冊默認的過濾器
registerDefaultFilters();
}
setEnvironment(environment);
setResourceLoader(resourceLoader);
}
protected void registerDefaultFilters() {
// includeFilters添加了一個AnnotationTypeFilter，過濾器構造器傳入了Component的Class對象
this.includeFilters.add(new AnnotationTypeFilter(Component.class));
// 省略了兩個JSR規範註解的註冊代碼，我們一般用不到，@javax.annotation.ManagedBean和@javax.inject.Named
}
由於Filter的匹配過程不是主流程，不在這裏多寫，但是我會寫一段源碼解析到這一節的末尾，感興趣的同學也可以看一下。
我們解析來看一下類型過濾器標籤的解析：
protected void parseTypeFilters(Element element, ClassPathBeanDefinitionScanner scanner, ParserContext parserContext) {
// ...
NodeList nodeList = element.getChildNodes();
for (int i = 0; i < nodeList.getLength(); i++) {
Node node = nodeList.item(i);
// 找到每一個子節點
if (node.getNodeType() == Node.ELEMENT_NODE) {
String localName = parserContext.getDelegate().getLocalName(node);
if (INCLUDE_FILTER_ELEMENT.equals(localName)) {
// 如果是<include-filter/>標籤則創建一個Filter並加入includeFilters
TypeFilter typeFilter = createTypeFilter((Element) node, classLoader, parserContext);
scanner.addIncludeFilter(typeFilter);
}
else if (EXCLUDE_FILTER_ELEMENT.equals(localName)) {
// 如果是<exclude-filter/>標籤則創建一個Filter並加入includeFilters
TypeFilter typeFilter = createTypeFilter((Element) node, classLoader, parserContext);
scanner.addExcludeFilter(typeFilter);
}
}
}
}
那麼我們看一下createTypeFilter究竟做了一些什麼：
// 邏輯還是比較直觀的
protected TypeFilter createTypeFilter(Element element, @Nullable ClassLoader classLoader,
ParserContext parserContext) {
String filterType = element.getAttribute(FILTER_TYPE_ATTRIBUTE);
String expression = element.getAttribute(FILTER_EXPRESSION_ATTRIBUTE);
expression = parserContext.getReaderContext().getEnvironment().resolvePlaceholders(expression);
if ("annotation".equals(filterType)) {
// 如果我們想掃描自定義的註解，那可以使用這個annotation類型，expression填註解全限定名就好了
return new AnnotationTypeFilter((Class<Annotation>) ClassUtils.forName(expression, classLoader));
}
else if ("assignable".equals(filterType)) {
// 掃描配置的類及其子類，expression填類的全限定名就好了，這個也偶爾用到，主要用來指定掃描一些二方庫的bean
return new AssignableTypeFilter(ClassUtils.forName(expression, classLoader));
}
else if ("aspectj".equals(filterType)) {
// 掃描切面表達式所匹配的類
return new AspectJTypeFilter(expression, classLoader);
}
else if ("regex".equals(filterType)) {
// 掃描正則表達式所匹配的類
return new RegexPatternTypeFilter(Pattern.compile(expression));
}
else if ("custom".equals(filterType)) {
// 自定義的過濾器，對應的類需要實現TypeFilter接口
Class<?> filterClass = ClassUtils.forName(expression, classLoader);
if (!TypeFilter.class.isAssignableFrom(filterClass)) {
throw new IllegalArgumentException(
"Class is not assignable to [" + TypeFilter.class.getName() + "]: " + expression);
}
return (TypeFilter) BeanUtils.instantiateClass(filterClass);
}
else {
throw new IllegalArgumentException("Unsupported filter type: " + filterType);
}
}
好了，context:component-scan標籤的屬性解析就告一段落了，我們主要記住base-package和Filter相關的就好了，其餘的其實也用不太到，畢竟這個掃描的功能主要只需要確定需要掃描哪些包以及需要關注哪些類就好了。那麼我們接下來再往回看一下，掃描器的掃描邏輯是怎麼樣的，同學們可以空降ComponentScanBeanDefinitionParser#parse，然後我們來看一下獲取到scanner之後，scanner.doScan(basePackages)的邏輯：
protected Set<BeanDefinitionHolder> doScan(String... basePackages) {
for (String basePackage : basePackages) {
// 找到所以掃描到的beanDefinition
Set<BeanDefinition> candidates = findCandidateComponents(basePackage);
for (BeanDefinition candidate : candidates) {
// 獲取beanName，要知道，我們使用註解的時候，其實是沒有一個像xml標籤屬性那樣的東西來獲取name的
// 這裏通過beanNameGenerator來獲取了beanName，默認就是通過註解內的對應屬性或者類名。感興趣的同學可以看下 AnnotationBeanNameGenerator
String beanName = this.beanNameGenerator.generateBeanName(candidate, this.registry);
// 刪掉了一下不重要的屬性的賦值
if (candidate instanceof AnnotatedBeanDefinition) {
// 裏是處理類上的一些公共註解的地方，比如@Primary，@Lazy等
AnnotationConfigUtils.processCommonDefinitionAnnotations((AnnotatedBeanDefinition) candidate);
}
// 這個判斷的大概意思就是，看一下我們掃描出來的beanDifinition是不是第一次註冊
// 如果不是第一次註冊就不會再註冊了，是通過beanName來從IOC容器中找有沒有一樣的
if (checkCandidate(beanName, candidate)) {
// ...
// 註冊bean，這個邏輯我們第一篇看過了，就不在看了，實際上就是把beanDefinition放入
// beanDefinitionMap和beanDefinitionNames這兩個容器裏面
registerBeanDefinition(definitionHolder, this.registry);
}
}
}
return beanDefinitions;
}
我們先看一下是怎麼AnnotationConfigUtils.processCommonDefinitionAnnotations()中是怎麼處理類上的註解的：
static void processCommonDefinitionAnnotations(AnnotatedBeanDefinition abd, AnnotatedTypeMetadata metadata) {
AnnotationAttributes lazy = attributesFor(metadata, Lazy.class);
if (lazy != null) {
abd.setLazyInit(lazy.getBoolean("value"));
}
else if (abd.getMetadata() != metadata) {
lazy = attributesFor(abd.getMetadata(), Lazy.class);
if (lazy != null) {
abd.setLazyInit(lazy.getBoolean("value"));
}
}
if (metadata.isAnnotated(Primary.class.getName())) {
abd.setPrimary(true);
}
AnnotationAttributes dependsOn = attributesFor(metadata, DependsOn.class);
if (dependsOn != null) {
abd.setDependsOn(dependsOn.getStringArray("value"));
}
AnnotationAttributes role = attributesFor(metadata, Role.class);
if (role != null) {
abd.setRole(role.getNumber("value").intValue());
}
AnnotationAttributes description = attributesFor(metadata, Description.class);
if (description != null) {
abd.setDescription(description.getString("value"));
}
}
大聰明們肯定已經發現了，其實就是看一下類上面有沒有對應的註解，然後把對應的屬性塞入beanDefinition對象嘛。這豈不是可以說是跟XML解析獲取beanDefinition時的流程一模一樣的？
是的，其實不管是基於註解還是基於xml，都是把一些描述bean的信息，收集彙總到相應的beanDefinition中而已。而beanDefinition的屬性決定了這個bean會怎麼實例化，需要注入哪些屬性等等等等。
收集信息來註解beanDefinition的途徑可以有多種–甚至你自己寫一個解析json格式文件的組件也不是不行，但是結果都是殊途同歸的。
從這也可以看出spring設計的強大，這種模塊化的設計思想和對單一職責原則（比較直觀的是各種委託模式，專業的事給專業的類做）和開閉原則（到我們現在講到的地方：自定義標籤的設計，在不觸動原有核心邏輯的情況下，我們可以很簡單的對spring做一些自定義的拓展）的實踐，我們日常開發中是否也可以借鑑借鑑呢？
好了，感慨完了，我們繼續回到源碼，接下來我們具體看下掃描器是怎麼掃描到那些被註解標記的類的（其實就是對之前註冊的過濾器的應用），findCandidateComponents()中調用了scanCandidateComponents()，我們之間看scanCandidateComponents()：
// 去除掉了異常處理和日誌打印
private Set<BeanDefinition> scanCandidateComponents(String basePackage) {
Set<BeanDefinition> candidates = new LinkedHashSet<>();
String packageSearchPath = ResourcePatternResolver.CLASSPATH_ALL_URL_PREFIX +
resolveBasePackage(basePackage) + '/' + this.resourcePattern;
// 這一段邏輯極其複雜切對我們理解主流程沒太大幫助，我們就不看了（主要是涉及到模糊匹配的文件尋找）
// 大概就是把所有符合的類文件找出來了
Resource[] resources = getResourcePatternResolver().getResources(packageSearchPath);
for (Resource resource : resources) {
// 解析文件信息，加載到內存，這裏看下去也賊複雜，都是一些字節碼解析技術了
// 我們只需要知道這樣操作一番後，這個MetadataReader能拿到我們這個類的所有信息就好了
MetadataReader metadataReader = getMetadataReaderFactory().getMetadataReader(resource);
// 這裏就是我們過濾器發揮作用的地方了，符合條件的類纔會生成beanDefinition
if (isCandidateComponent(metadataReader)) {
ScannedGenericBeanDefinition sbd = new ScannedGenericBeanDefinition(metadataReader);
sbd.setResource(resource);
sbd.setSource(resource);
// 這裏主要判斷一下，我們匹配到的類是不是一個符合條件的bean
// 比如說如果我們註解打在接口上，這裏就不會把這個beanDefinition加入返回的容器了
if (isCandidateComponent(sbd)) {
candidates.add(sbd);
}
}
}
return candidates;
}
// 過濾器判斷是否是我們關注的類，邏輯很直觀
protected boolean isCandidateComponent(MetadataReader metadataReader) throws IOException {
// 先判斷的excludeFilters
for (TypeFilter tf : this.excludeFilters) {
if (tf.match(metadataReader, getMetadataReaderFactory())) {
return false;
}
}
// 再判斷的includeFilters
for (TypeFilter tf : this.includeFilters) {
if (tf.match(metadataReader, getMetadataReaderFactory())) {
// 如果是我們關注的類，還需要處理類上面的@Conditional註解
// 這裏不繼續往下拓展了，我簡單講一下邏輯：
// 1.找到類上面所有的@Conditional簇的註解
// 2.實例化所有對應的Conditional類，並排序
// 3.依次調用所有condition.matches()，所有條件全部滿足才返回true
// 具體細節同學們感興趣可以自己看下
return isConditionMatch(metadataReader);
}
}
return false;
}
// 判斷是否不是接口那些
protected boolean isCandidateComponent(AnnotatedBeanDefinition beanDefinition) {
return (metadata.isIndependent() // 不是實例內部類 並且
&& (metadata.isConcrete() // 不是接口或者抽象類 或者
||
(metadata.isAbstract() && metadata.hasAnnotatedMethods(Lookup.class.getName()))));
// 是抽象類但是有些方法被@Lookup註解標記，這個之前有稍微提過，xml標籤裏那個lookup-method標籤跟這個是一個意思，相當於把這個方法委託/代理給另一個bean了，所以即使是抽象類也是可以變成一個bean的 -> spring動態代理生成一個子類
}
那麼其實看到這裏，我們已經明白了context:component-scan標籤是怎麼掃描，怎麼支持@Component註解的了，但是細心的同學們可能已經發現了，現在我們確實能掃描@Component註解了，但是我們bean中那些屬性是怎麼注入的呢？@Autowrite、@Resource這些註解是怎麼支持的呢？以及@Configuration、@Bean又是如何支持的呢？
預知後事如何，請看下篇博客，哈哈哈~
3. Filter匹配流程
本來不想寫Filter的匹配流程的，因爲其實不是主流程，不過想想還是寫一下吧，不然有些同學可能會糾結。
主要講一下我們用的比較多的AnnotationTypeFilter，先看一下AnnotationTypeFilter的構造器：
// 我們簡單看一下AnnotationTypeFilter的構造器
public AnnotationTypeFilter(Class<? extends Annotation> annotationType) {
this(annotationType, true, false);
}
// 可以看到，我們掃描@Component註解時，是考慮源註解，且不考慮接口上的註解的
public AnnotationTypeFilter(
// 註解類型
Class<? extends Annotation> annotationType,
// 是否考慮源註解
boolean considerMetaAnnotations,
// 是否考慮接口
boolean considerInterfaces) {
// 第一個參數是是否考慮繼承的註解
super(annotationType.isAnnotationPresent(Inherited.class), considerInterfaces);
this.annotationType = annotationType;
this.considerMetaAnnotations = considerMetaAnnotations;
}
再看一下核心的match方法，這裏也是一個模板方法模式：
// 先看頂層類
public abstract class AbstractTypeHierarchyTraversingFilter implements TypeFilter {
@Override
public boolean match(MetadataReader metadataReader, MetadataReaderFactory metadataReaderFactory)
throws IOException {
// 直接看當前類是否匹配 - 模板方法，由子類實現，默認返回了false
if (matchSelf(metadataReader)) {
return true;
}
// 提供一個通過className判斷是否匹配的鉤子
ClassMetadata metadata = metadataReader.getClassMetadata();
if (matchClassName(metadata.getClassName())) {
return true;
}
if (this.considerInherited) {
// 如果考慮繼承的註解，則找到對應的父類
String superClassName = metadata.getSuperClassName();
if (superClassName != null) {
// 先看下子類有沒有 單獨判斷父類是否匹配 的邏輯
Boolean superClassMatch = matchSuperClass(superClassName);
if (superClassMatch != null) {
// 有寫這個邏輯則直接用這個返回結果了
if (superClassMatch.booleanValue()) {
return true;
}
}
else {
// 沒有 單獨判斷父類是否匹配 的邏輯 則直接走當前這個匹配邏輯
if (match(metadata.getSuperClassName(), metadataReaderFactory)) {
return true;
}
}
}
}
if (this.considerInterfaces) {
// 如果考慮接口的註解，則找到對應的接口，因爲接口是多個，所以要循環
// 邏輯和父類那裏類似，不多講了
for (String ifc : metadata.getInterfaceNames()) {
Boolean interfaceMatch = matchInterface(ifc);
if (interfaceMatch != null) {
if (interfaceMatch.booleanValue()) {
return true;
}
}
else {
if (match(ifc, metadataReaderFactory)) {
return true;
}
}
}
}
return false;
}
}
再看一下AnnotationTypeFilter的幾個核心方法：
public class AnnotationTypeFilter extends AbstractTypeHierarchyTraversingFilter {
protected boolean matchSelf(MetadataReader metadataReader) {
AnnotationMetadata metadata = metadataReader.getAnnotationMetadata();
// 類上有目標註解
return metadata.hasAnnotation(this.annotationType.getName()) ||
// 如果可以從源註解拿，則找一下類上面有沒有源註解是和目標註解一樣的
(this.considerMetaAnnotations && metadata.hasMetaAnnotation(this.annotationType.getName()));
}
protected Boolean matchSuperClass(String superClassName) {
return hasAnnotation(superClassName);
}
protected Boolean matchInterface(String interfaceName) {
return hasAnnotation(interfaceName);
}
@Nullable
protected Boolean hasAnnotation(String typeName) {
if (Object.class.getName().equals(typeName)) {
return false;
}
// 這個父類和接口的匹配邏輯居然只能匹配到jdk內置（java開頭）的類
// 看來默認的實現應該是用來支持JSR標準的那些註解的
else if (typeName.startsWith("java")) {
// ... 不關注
}
return null;
}
}
我們可以看到，我們默認的AnnotationTypeFilter是考慮源註解的，那麼這個源註解到底是個什麼東西呢？
public @interface Controller {
@AliasFor(annotation = Component.class)
String value() default "";
}
public @interface Service {
@AliasFor(annotation = Component.class)
String value() default "";
}
public @interface Repository {
@AliasFor(annotation = Component.class)
String value() default "";
}
常見的就是這個東西啦@AliasFor(annotation = Component.class)，這也是爲什麼我們默認的includeFilters明明只註冊了一個@Component類型的AnnotationTypeFilter，但是我們@Service等也能被掃描到的原因啦！我們構造的AnnotationTypeFilter是考慮源註解的！
三、實踐
都說實踐出真知，我們跟着源碼分析了這麼一大波，但是事實是不是如我們分析的那樣呢？爲了證實一下，這邊我簡單使用一下spring預留的拓展點。
1. 使用context:component-scan掃描自定義註解
我們首先需要自定義一個註解：
@Target({ElementType.TYPE})
@Retention(RetentionPolicy.RUNTIME)
public @interface MyService {
}
然後配置一下context:component-scan標籤：
<context:component-scan base-package="com.xiaoxizi.spring">
<context:include-filter type="annotation" expression="com.xiaoxizi.spring.annotation.MyService"/>
</context:component-scan>
爲我們的業務類打上註解：
@Data
@MyService
public class MyAnnoClass {
public String username = "xiaoxizi";
}
運行：
public void test1() {
applicationContext = new ClassPathXmlApplicationContext("spring.xml");
MyAnnoClass myAnnoClass = applicationContext.getBean(MyAnnoClass.class);
System.out.println(myAnnoClass);
}
輸出結果：
MyAnnoClass(username=xiaoxizi)
說明我們的自定義註解掃描到了，並且成功生成了beanDefinition並實例化了bean！
2. 自定義標籤
先創建一個具體標籤的解析類，我們這邊簡單點，直接繼承了spring內部的一個類：
public class SimpleBeanDefinitionParse extends AbstractSingleBeanDefinitionParser {
@Override
protected String getBeanClassName(final Element element) {
System.out.println("SimpleBeanDefinitionParse ... getBeanClassName()");
return element.getAttribute("className");
}
}
然後創建一個SimpleNamespaceHandler：
public class SimpleNamespaceHandler extends NamespaceHandlerSupport {
@Override
public void init() {
System.out.println("SimpleNamespaceHandler ... init()");
this.registerBeanDefinitionParser("simpleBean", new SimpleBeanDefinitionParse());
}
}
配置寫入META-INF/spring.handlers文件：
http\://www.xiaoxize.com/schema/simple=com.xiaoxizi.spring.tag.SimpleNamespaceHandler
xml配置中使用：
<xiaoxizi:simple className="com.xiaoxizi.spring.bean.MyAnnoClass"/>
<!-- 該標籤對應的命名空間在xml文件頭部beans標籤中聲明 -->
<beans xmlns:xiaoxizi="http://www.xiaoxize.com/schema/simple" ... />
目標類：
@Data
// @MyService
public class MyAnnoClass {
public String username = "xiaoxizi";
}
運行：
public void test1() {
applicationContext = new ClassPathXmlApplicationContext("spring.xml");
MyAnnoClass myAnnoClass = applicationContext.getBean(MyAnnoClass.class);
System.out.println(myAnnoClass);
}
輸出結果-各種報錯，哈哈哈：
Caused by: org.xml.sax.SAXParseException; lineNumber: 21; columnNumber: 91; cvc-complex-type.2.4.c: 通配符的匹配很全面, 但無法找到元素 'xiaoxizi:simple' 的聲明。
emmmm，翻車車啦~這裏還是卡了一會的，主要是對xml規範的不熟悉導致的，原來我們在聲明命名空間的時候，還要聲明並定義對應的XSD文件，（這裏我自己寫了一個xsd文件，並通過idea的配置引入了工作空間）像這樣：
<xiaoxizi:simple className="com.xiaoxizi.spring.bean.MyAnnoClass"/>
<!-- 該標籤對應的命名空間在xml文件頭部beans標籤中聲明 -->
<beans xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xiaoxizi="http://www.xiaoxize.com/schema/simple"
xsi:schemaLocation="
http://www.xiaoxize.com/schema/simple
http://www.xiaoxize.com/schema/simple.xsd"
... />
然後發現還是不行：
java.net.UnknownHostException: www.xiaoxize.com
org.xml.sax.SAXParseException: schema_reference.4: 無法讀取方案文檔 'http://www.xiaoxize.com/schema/simple.xsd', 原因爲 1) 無法找到文檔; 2) 無法讀取文檔; 3) 文檔的根元素不是 <xsd:schema>。
Caused by: org.xml.sax.SAXParseException; lineNumber: 21; columnNumber: 91; cvc-complex-type.2.4.c: 通配符的匹配很全面, 但無法找到元素 'xiaoxizi:simple' 的聲明。
啊，原來spring解析這個xml的時候，是不歸idea管的，他還是會去對應的域名下找這個xsd文件（而我根本沒有xiaoxizi這個域名…），最後我把xsd文件丟到自己服務器上，並且調整了域名那些，終於可以了：
SimpleNamespaceHandler ... init()
SimpleBeanDefinitionParse ... getBeanClassName()
MyAnnoClass(username=xiaoxizi)
大功告成，所以自定義標籤還是蠻簡單的嘛（認真臉！
四、總結
1. 自定義標籤解析過程
- 第一個自定義標籤開始解析時，將會從所有
jar包的META-INF/spring.handlers文件加載 自定義標籤命名空間-對應NamespaceHandler全限定名到內存中的DefaultNamespaceHandlerResolver.handlerMappings - 同樣前綴的自定義標籤第一次解析時，將會實例化對應的
NamespaceHandler，並調用其init()方法，然後把自定義標籤命名空間-對應NamespaceHandler實例放入handlerMappings，下次再有同樣的標籤過來解析，就直接能拿到對應的NamespaceHandler實例了 - 使用找到的
NamespaceHandler實例的parse方法解析自定義標籤 spring貼心的爲我們準備了NamespaceHandler相關的模版類NamespaceHandlerSupport，如果我們自定義的處理器繼承了這個模版，那隻需要在init方法中爲具體的標籤注入相應的BeanDefinitionParser或者BeanDefinitionDecorator就可以實現功能了
2. @Component，@Service等註解的實現原理
本來這一篇是打算講完所有context:component-scan標籤做的事情的，但是由於篇幅問題，沒講完，剩下的只能之後再講了。
- 自定義標籤
context:component-scan對應的解析器是ComponentScanBeanDefinitionParser（找的過程我們不贅述了）。 - 解析器的
parse方法中，我們通過標籤配置的屬性創建了一個掃描器ClassPathBeanDefinitionScanner - 默認情況下， 我們會註冊一個
@Component註解的AnnotationTypeFilter，並且註冊到掃描器的includeFilters中 - 然後掃描器開始掃描
basePackage下所有的java類，並且找到所有不需要排除（excludeFilters）的候選類（includeFilters），然後爲其生成一個beanDefinition，如果該類是一個合法的beanDefinition（非接口那些判斷），那麼就會將這些beanDefinition收集起來並返回 - 對於所有的候選
beanDefinition，掃描器還會進一步掃描類上的@Lazy、@Primary、@DependsOn等屬性，然後設值到beanDefinition的對應屬性中 - 最後一步，把我們所有掃描到的所有合法的
beanDefinition註冊到IOC容器 - 由於
@Component是@Service、@Controller等註解的源註解，所以@Service這些註解標記的類也會被includeFilters掃描到
五、其他
實踐中使用的的簡單的XSD文件
<xsd:attribute name="className" type="xsd:string"></xsd:attribute>
<?xml version="1.0" encoding="UTF-8"?>
<xsd:schema xmlns="http://你的ip或者域名/simple"
xmlns:xsd="http://www.w3.org/2001/XMLSchema" targetNamespace="http://你的ip或者域名/simple"
elementFormDefault="qualified">
<xsd:element name="simple">
<xsd:complexType>
<xsd:attribute name="className" type="xsd:string"></xsd:attribute>
<xsd:attribute name="id" type="xsd:string"></xsd:attribute>
</xsd:complexType>
</xsd:element>
</xsd:schema>
這一篇寫完感覺要把自己榨乾了，好難寫好多字…而且沒有存稿了，之後的更新肯定會比較慢了~