這期內(nèi)容當(dāng)中小編將會給大家?guī)碛嘘P(guān)Tomcat目錄部署與Context描述文件context.xml的示例分析，文章內(nèi)容豐富且以專業(yè)的角度為大家分析和敘述，閱讀完這篇文章希望大家可以有所收獲。

專注于為中小企業(yè)提供成都網(wǎng)站建設(shè)、成都網(wǎng)站設(shè)計服務(wù),電腦端+手機(jī)端+微信端的三站合一,更高效的管理,為中小企業(yè)濟(jì)源免費(fèi)做網(wǎng)站提供優(yōu)質(zhì)的服務(wù)。我們立足成都，凝聚了一批互聯(lián)網(wǎng)行業(yè)人才，有力地推動了上千多家企業(yè)的穩(wěn)健成長，幫助中小企業(yè)通過網(wǎng)站建設(shè)實現(xiàn)規(guī)模擴(kuò)充和轉(zhuǎn)變。

在Web應(yīng)用開發(fā)完畢后，一些項目有時候采用目錄部署的形式，而且是在server.xml中增加Context配置的形式，例如下面這種形式：

<Contextpath="/test" docBase="/home/abc/test"/>

但是官方并不鼓勵這樣配置，可以通過兩種在外部文件配置的形式，不影響Tomcat主配置來實現(xiàn)同樣的效果。

1. $CATALINA_BASE/conf/[enginename]/[hostname]/[webappname].xml

2. $CATALINA_BASE/webapps/[webappname]/META-INF/context.xml

前面曾寫過Tomcat的應(yīng)用部署(WEB應(yīng)用是怎么被部署的?，如何在Tomcat中部署應(yīng)用的多個版本)，當(dāng)時沒有詳細(xì)介紹context.xml。

關(guān)于上面提到的這兩種形式，內(nèi)容一樣，只是在不同的位置進(jìn)行配置，例如上面在server.xml中配置的內(nèi)容，可以在創(chuàng)建一個名為test.xml的文件，將其存放在Tomcat的conf/localhost/test.xml，即上面兩項的第一種情況，這里注意應(yīng)用的名稱會直接使用文件名，path的配置會被忽略。

嚴(yán)格來說，第二種并不能直接替換前面server.xml里的情況，所能解決的是對于webapps目錄內(nèi)部署應(yīng)用的額外配置，例如manager這個應(yīng)用，要增加遠(yuǎn)程訪問限制(為什么你的Manager登錄不成功?），就是通過第二種，在META-INF目錄內(nèi)增加context.xml來實現(xiàn)的。

而實質(zhì)上這兩種統(tǒng)一稱為Context的描述文件(Context Descriptor)。這些描述文件里包含一些應(yīng)用對于Context的特定配置，例如配置Session Manager，指定naming Resrouce，定義SessionCookie名稱等。使用描述文件，相當(dāng)于給Context做了自定義，沒提供描述文件的應(yīng)用，Tomcat就會直接使用默認(rèn)值初始化應(yīng)用。

而且還有一點(diǎn)，使用描述文件定義的應(yīng)用，會先部署。

下面來看源代碼

源碼

在HostConfig中，所有的部署從這兒開始。

protected void deployApps() {

   File appBase = host.getAppBaseFile();
   File configBase = host.getConfigBaseFile();
   String[] filteredAppPaths = filterAppPaths(appBase.list());
   // Deploy XML descriptors from configBase
   deployDescriptors(configBase, configBase.list());
   // Deploy WARs
   deployWARs(appBase, filteredAppPaths);
   // Deploy expanded folders
   deployDirectories(appBase, filteredAppPaths);

}

我們看到部署順序：

1. 部署XML描述文件

2. 部署WAR應(yīng)用

3. 部署解壓的Web應(yīng)用

其中讀取應(yīng)用的目錄就是各個Host對應(yīng)的appBase對應(yīng)的配置，我們常用的webapps目錄是虛擬主機(jī)localhost默認(rèn)對應(yīng)的位置。

部署描述符,即第一種webappname.xml的時候，會從configBase中遍歷所有以xml描述文件，然后部署之。

for (int i = 0; i < files.length; i++) {
   File contextXml = new File(configBase, files[i]);

   if (files[i].toLowerCase(Locale.ENGLISH).endsWith(".xml")) {
       ContextName cn = new ContextName(files[i], true);// 看這里

       if (isServiced(cn.getName()) || deploymentExists(cn.getName()))
           continue;

       results.add(
               es.submit(new DeployDescriptor(this, cn, contextXml)));
   }
}

for (Future result : results) {
   try {
       result.get();
   } catch (Exception e) {
       log.error(sm.getString(
               "hostConfig.deployDescriptor.threaded.error"), e);
   }
}

其中注意ContextName生成那行代碼，是直接使用了文件名進(jìn)行Context的設(shè)置，ContextName我們前面文章看過源代碼，這里配置的就是path，即實際請求的應(yīng)用名稱。

然后實際部署時，先通過Digester解析文件獲取Context對象，再進(jìn)行屬性配置，之后的部署流程和其它的一致。

在StandardContext的初始化流程中，會判斷獲取之前設(shè)置的configFile對象，不為空會解析文件內(nèi)容。

而我們上面的第二種方式：為應(yīng)用提供context.xml，在Tomcat代碼內(nèi)，稱之為ApplicationContextXml。

這個文件是在第二和第三個部署的時候，解析META-INF目錄下是否包含context.xml，然后設(shè)置Context的configFile屬性。初始化Context的時候，會有如下邏輯

if (context.getConfigFile() != null) {
   processContextConfig(digester, context.getConfigFile());
}

這個就是前面webappname.xml解析時設(shè)置configFile之后走的流程，在ContextConfig中。

這樣一來，我們的自定義配置文件就在Tomcat中生效了。

上述就是小編為大家分享的Tomcat目錄部署與Context描述文件context.xml的示例分析了，如果剛好有類似的疑惑，不妨參照上述分析進(jìn)行理解。如果想知道更多相關(guān)知識，歡迎關(guān)注創(chuàng)新互聯(lián)行業(yè)資訊頻道。