從SpringApplication開始

一般情況下啟動SpringBoot都是新建一個類包含main方法，然後使用SpringApplication.run來啟動程序：

@SpringBootApplication
public class AutoConfigApplication {

    public static void main(String[] args){
        ConfigurableApplicationContext configurableApplicationContext = SpringApplication.run(AutoConfigApplication.class,args);
    }
}

SpringApplication.run接收兩個參數分別為：primarySource、運行參數（args），上面的代碼使用AutoConfigApplication.class作為primarySource。SpringApplication還有一個實例方法也叫run，SpringBoot的大部分啟動都由實例run方法來完成的，其中構造ApplicationContext由createApplicationContext方法完成：

protected ConfigurableApplicationContext createApplicationContext() {
        Class<?> contextClass = this.applicationContextClass;
        if (contextClass == null) {
            try {
                switch (this.webApplicationType) {
                case SERVLET:
                    contextClass = Class.forName(DEFAULT_SERVLET_WEB_CONTEXT_CLASS);
                    break;
                case REACTIVE:
                    contextClass = Class.forName(DEFAULT_REACTIVE_WEB_CONTEXT_CLASS);
                    break;
                default:
                    contextClass = Class.forName(DEFAULT_CONTEXT_CLASS);
                }
            }
            catch (ClassNotFoundException ex) {
                throw new IllegalStateException(
                        "Unable create a default ApplicationContext, please specify an ApplicationContextClass", ex);
            }
        }
        return (ConfigurableApplicationContext) BeanUtils.instantiateClass(contextClass);
    }

createApplicationContext根據this.webApplicationType來構造ApplicationContext，不同的環境都會使用不同的實例，但本文非web環境所有構造的時候會使用AnnotationConfigApplicationContext類。創建AnnotationConfigApplicationContext的時候會調用默認構造方法：

public AnnotationConfigApplicationContext() {
    this.reader = new AnnotatedBeanDefinitionReader(this);
    this.scanner = new ClassPathBeanDefinitionScanner(this);
}

AnnotationConfigApplicationContext默認構造函數創建兩個對象：

• reader（AnnotatedBeanDefinitionReader）：用於手動註冊bean
• scanner（ClassPathBeanDefinitionScanner）: 用於掃描Component、Repository、Service等註解

AnnotatedBeanDefinitionReader和ClassPathBeanDefinitionScanner會註冊一些註解處理器，註冊的方式都是使用AnnotationConfigUtils的registerAnnotationConfigProcessors方法：

public static Set<BeanDefinitionHolder> registerAnnotationConfigProcessors(
            BeanDefinitionRegistry registry, @Nullable Object source) {

        ...
        
        if (!registry.containsBeanDefinition(CONFIGURATION_ANNOTATION_PROCESSOR_BEAN_NAME)) {
            RootBeanDefinition def = new RootBeanDefinition(ConfigurationClassPostProcessor.class);
            def.setSource(source);
            beanDefs.add(registerPostProcessor(registry, def, CONFIGURATION_ANNOTATION_PROCESSOR_BEAN_NAME));
        }
        ...
        return beanDefs;
    }

最終AnnotationConfigApplicationContext構造方法執行完成后ApplicationContext會有以下BeanDefinition：

構造完ApplicationContext后SpringApplicaiton緊接着會加載primarySource，上面提到 過primarySource是在運行的時候傳遞進來的（AutoConfigApplication.class），加載過程中不貼代碼了，只要知道最終ApplicaitonContext中會多一個AutoConfigApplication的BeanDefinition：

小結

總的來說SpringApplicaiton主要幹了這些事：

• 創建AnnotationConfigApplicationContext
• 加載一些處理註解的后處理器如：ConfigurationClassPostProcessor
• 將primarySource加載進ApplicationContext

最重要的一點是，現在是有一個AnnotationConfigApplicationContext裡面包含了primarySource（AutoConfigApplication）以及ConfigurationClassPostProcessor。打個斷點在ApplicaitonContext刷新之前打印下context中的bean的名稱，可以確定這樣說沒毛病！

@Configuration啥時候被解析？

雖說有了primarySource和ConfigurationClassPostProcessor后處理器，還是需要有個執行的入口。ConfigurationClassPostProcessor是BeanDefinitionRegistryPostProcessor的實現類，BeanDefinitionRegistryPostProcessor會在ApplicationContext的refresh操作時被處理：

public void refresh() throws BeansException, IllegalStateException {
        synchronized (this.startupShutdownMonitor) {
            ...
            invokeBeanFactoryPostProcessors(beanFactory);
            ...
        }
}
    
public static void invokeBeanFactoryPostProcessors(
            ConfigurableListableBeanFactory beanFactory, List<BeanFactoryPostProcessor> beanFactoryPostProcessors) {
        
        ...
        //找出所有類型為BeanDefinitionRegistryPostProcessor的bean的名稱
        String[] postProcessorNames =
                    beanFactory.getBeanNamesForType(BeanDefinitionRegistryPostProcessor.class, true, false);
        for (String ppName : postProcessorNames) {
            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);
        ...
}

private static void invokeBeanDefinitionRegistryPostProcessors(
        Collection<? extends BeanDefinitionRegistryPostProcessor> postProcessors, BeanDefinitionRegistry registry) {

    for (BeanDefinitionRegistryPostProcessor postProcessor : postProcessors) {
        //調用postProcessBeanDefinitionRegistry方法
        postProcessor.postProcessBeanDefinitionRegistry(registry);
    }
}   

invokeBeanDefinitionRegistryPostProcessors會調用BeanDefinitionRegistryPostProcessor的postProcessBeanDefinitionRegistry方法，通過斷點調試工具確認下ConfigurationClassPostProcessor有沒有在這一步被處理：

調試輸出postProcessors集合裏面有一個了ConfigurationClassPostProcessor元素，說明了ConfigurationClassPostProcessor的執行入口沒有問題。

ConfigurationClassPostProcessor處理器

ConfigurationClassPostProcessor首先會判斷在ApplicationContext中的bean是否被@Configuration註解標記，然後使用ConfigurationClassParser來解析@Configuration，ConfigurationClassPostProcessor的解析@Configuration的大致流程：

1. 使用ConfigurationClassUtils.checkConfigurationClassCandidate檢查BeanDefinition是否@Configuration註解標記
2. 對@Configuration進行排序
3. 使用ConfigurationClassParser解析@Configuration註解的信息
4. 使用ConfigurationClassBeanDefinitionReader解析BeanDefinition

public void processConfigBeanDefinitions(BeanDefinitionRegistry registry) {
        List<BeanDefinitionHolder> configCandidates = new ArrayList<>();
        
        //獲取所有BeanDefinitio名稱
        String[] candidateNames = registry.getBeanDefinitionNames();
        
        for (String beanName : candidateNames) {
            BeanDefinition beanDef = registry.getBeanDefinition(beanName);
            //如果是full、lite則說明已經處理過的類
            if (ConfigurationClassUtils.isFullConfigurationClass(beanDef) ||
                    ConfigurationClassUtils.isLiteConfigurationClass(beanDef)) {
                if (logger.isDebugEnabled()) {
                    logger.debug("Bean definition has already been processed as a configuration class: " + beanDef);
                }
            }
            //檢查BeanDefinition是否有@Configuration註解
            else if (ConfigurationClassUtils.checkConfigurationClassCandidate(beanDef, this.metadataReaderFactory)) {
                configCandidates.add(new BeanDefinitionHolder(beanDef, beanName));
            }
        }

        //如果沒有找到@Configuration標記的類，則返回不作處理也
        if (configCandidates.isEmpty()) {
            return;
        }

        //對@Configuration進行排序
        configCandidates.sort((bd1, bd2) -> {
            int i1 = ConfigurationClassUtils.getOrder(bd1.getBeanDefinition());
            int i2 = ConfigurationClassUtils.getOrder(bd2.getBeanDefinition());
            return Integer.compare(i1, i2);
        });
        
        ...
  
        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 {
            //解析@Configuration class
            parser.parse(candidates);
            parser.validate();

            Set<ConfigurationClass> configClasses = new LinkedHashSet<>(parser.getConfigurationClasses());
            configClasses.removeAll(alreadyParsed);

            //讀取BeanDefinition
            if (this.reader == null) {
                this.reader = new ConfigurationClassBeanDefinitionReader(
                        registry, this.sourceExtractor, this.resourceLoader, this.environment,
                        this.importBeanNameGenerator, parser.getImportRegistry());
            }
            this.reader.loadBeanDefinitions(configClasses);
            alreadyParsed.addAll(configClasses);

            candidates.clear();
            ...
        }
        while (!candidates.isEmpty());
        ...
    }

最後還是通過調試工具看一下示例中的的啟動類AutoConfigApplication沒有被處理：

圖上显示configCandidates中有一個名稱為autoConfigApplication的BeanDefinition的元素，說明AutoConfigApplication會被當作配置類解析，但是AutoConfigApplication並沒有使用@Configuration註解，為什麼還會被當做配置類呢？其實@Configuration在@SpringBootApplication註解中：

紅色背景列出來的就是@Configuration註解，它是@SpringBootConfiguration的元註解。

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

※帶您來了解什麼是 USB CONNECTOR  ?

※自行創業 缺乏曝光? 下一步”網站設計“幫您第一時間規劃公司的門面形象

※如何讓商品強力曝光呢? 網頁設計公司幫您建置最吸引人的網站，提高曝光率!!

※綠能、環保無空污,成為電動車最新代名詞，目前市場使用率逐漸普及化

※廣告預算用在刀口上，網站設計公司幫您達到更多曝光效益

※試算大陸海運運費!

　　Hello 大家好，我是TANZAME，我們又見面了。

　　NuGet 是什麼這裏就不再重複啰嗦，園子里一搜一大把。今天要跟大家分享的是，在日常開發過程中如何統一管理我們的包，如何通過批處理腳本生成包並自動上傳到 NuGet。在實際項目開發過程中我們要上傳自己的包，一般的步驟都是：nuget spec => nuget pack => nuget push，一個包都要至少重複三個動作，如果有 N 個包那就要重複 N*3 次，想想都不能忍，所以便有了今天的分享主題。

• 生成目錄

　　既然是統一管理，生成的包自然是放在同一個文件夾，而不是分散在各個 .proj 目錄里。這裏我們在解決方案所在目錄新建一個目錄，這樣做的目的是方便 bat 腳本找到解決方案下面的子項目。比如我這裏新建的是 .nuget 這個目錄，需要注意的是如果目錄名稱有特殊字符的話不能直接右鍵新建，需要用命令提示符，直接在解決方案所在目錄使用快捷鍵 SHIFT + 右鍵 就能直接打開命令提示符，這樣可以省去一大堆 cd 的操作。

• 下載 NuGet

　　到 NuGet 官網下載命令行接口(CLI）。nuget.exe提供了完整的 nuget 功能, 可用於安裝、創建、發布和管理包, 而無需對項目文件進行任何更改。

1. 請訪問 ，並選擇 NuGet 3.3 或更高版本（2.8.6 與 Mono 不兼容）。 始終建議使用最新版。若要將包發布到 nuget.org，版本至少必須是 4.1.0。
2. 每次下載都直接下載 nuget.exe 文件。 讓瀏覽器將文件保存到選定文件夾。 此文件不 是安裝程序；如果直接在瀏覽器中運行，就不會看到任何內容。
3. 將文件夾添加到 nuget.exe 中放置 PATH 環境變量的位置，這樣就可以從任意位置使用 CLI 工具。這裏我們把它放在上一步新建的 .nuget 文件夾下面，並設置 PATH 環境變量。

• 生成清單

　　是包含包元數據的 XML 清單， 此清單同時用於生成包以及為使用者提供信息。這個清單文件我們只需要生成一次，以後都不需要再重新生成。 .net Core 和使用sdk 特性.NET Standard 項目不需要 .nuspec 文件，如果是.net Core 和使用sdk 特性.NET Standard 項目則忽略此步驟。轉到項目所在目錄，SHIFT + 右鍵 調出命令提示符，輸入 nuget spec 命令即可生成我們所需要的包元數據清單。

　　將這個清單文件剪切到第一步新建的 .nuget 文件夾，剪切過去後項目下面就不會憑空多出一個文件，看着清爽多了。然後做一下調整填入我們自己項目的相關信息， 比如像下面這樣：

<?xml version="1.0" encoding="utf-8"?>
<package xmlns="http://schemas.microsoft.com/packaging/2013/05/nuspec.xsd">
  <metadata>
    <id>TZM.XFramework</id>
    <version>$version$</version>
    <title>$title$</title>
    <authors>$author$</authors>
    <owners>$author$</owners>
    <license type="expression">Apache-2.0</license>
    <projectUrl>https://github.com/TANZAME/TZM.XFramework</projectUrl>
    <iconUrl>http://go.microsoft.com/fwlink/?LinkID=386613</iconUrl>
    <description>TZM.XFramework is a lightweight and high performance object-relational mapper for .NET use the original Entity Framework api.</description>
    <copyright>Copyright 2019</copyright>
    <tags>.NET SqlServer MSSQL Database Data O/RM ADO.NET</tags>
    <repository type="git" url="https://github.com/TANZAME/TZM.XFramework" />
    <dependencies />
    <frameworkAssemblies>
      <frameworkAssembly assemblyName="System.Data"/>
      <frameworkAssembly assemblyName="System.ComponentModel.DataAnnotations"/>
      <frameworkAssembly assemblyName="System.Net.Http"/>
    </frameworkAssemblies>
  </metadata>
</package>

• 編寫腳本

　　在第一步新建的文件夾里新建一個 bat 文件，重命名為 package.bat，接下來編寫我們的自動腳本。完整 bat 腳本，直接上代碼片段。

1. 這裏我設置 nuget pack 包屬性為Release，並且不自動生成，所以需要先在 Release 模式下編譯完成再運行腳本。加上 -Build 參數的話輸出的信息太多看得賊難受，這裏把它去掉，我們自己手動編譯。
2. 填充api_key。去 nuget 官網 登錄自己的帳號並創建一個 key，複製粘貼到 api_key 變量。
3. 注意 .net framework 項目（fx）和 .net core 項目使用的命令不一樣
4. 至此我們所有的準備步驟都已完成，雙擊 package.bat 運行腳本，解放雙手。

@echo off
set api_key=xxxxxxlef2j57rw4q26qcrvycvznyvcurgfxbzxxxxxxxx
set source_api_uri=https://api.nuget.org/v3/index.json
set startup_dir=%~dp0
cd ..\
set startup_dir=%cd%
cd .nuget

:: 打包 TZM.XFramework -Build
echo pack TZM.XFramework
copy TZM.XFramework.nuspec %startup_dir%\net45\TZM.XFramework
nuget pack %startup_dir%\net45\TZM.XFramework\TZM.XFramework.csproj -Properties Configuration=Release
del %startup_dir%\net45\TZM.XFramework\TZM.XFramework.nuspec
echo=

:: 打包 TZM.XFrameworkCore
echo pack TZM.XFrameworkCore
dotnet pack --no-build --configuration Release --output %startup_dir%\.nuget\ %startup_dir%\netcore\TZM.XFrameworkCore\TZM.XFrameworkCore.csproj

:: 批量推送包
for /R %cd% %%f in (*.nupkg) do ( 
echo=
dotnet nuget push %%f -k %api_key% -s %source_api_uri%
)

echo=
pause

　　最後貼一張最終運行的效果圖：

• 總結

  　通過這個腳本，我們可以在一個文件夾里統一管理我們的包，做到一鍵生成、上傳同時保持項目文件的清爽，嗯簡直不要太方便 ~..~

　  參考資料：

　  技術交流群:816425449

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

※帶您來了解什麼是 USB CONNECTOR  ?

※自行創業 缺乏曝光? 下一步”網站設計“幫您第一時間規劃公司的門面形象

※如何讓商品強力曝光呢? 網頁設計公司幫您建置最吸引人的網站，提高曝光率!!

※綠能、環保無空污,成為電動車最新代名詞，目前市場使用率逐漸普及化

※廣告預算用在刀口上，網站設計公司幫您達到更多曝光效益

※試算大陸海運運費!