您好,登錄后才能下訂單哦!
這期內容當中小編將會給大家帶來有關Tomcat目錄部署與Context描述文件context.xml的示例分析,文章內容豐富且以專業的角度為大家分析和敘述,閱讀完這篇文章希望大家可以有所收獲。
在Web應用開發完畢后,一些項目有時候采用目錄部署的形式,而且是在server.xml中增加Context配置的形式,例如下面這種形式:
<Context path="/test" docBase="/home/abc/test"/>
但是官方并不鼓勵這樣配置,可以通過兩種在外部文件配置的形式,不影響Tomcat主配置來實現同樣的效果。
$CATALINA_BASE/conf/[enginename]/[hostname]/[webappname].xml
$CATALINA_BASE/webapps/[webappname]/META-INF/context.xml
前面曾寫過Tomcat的應用部署(WEB應用是怎么被部署的?,如何在Tomcat中部署應用的多個版本),當時沒有詳細介紹context.xml。
關于上面提到的這兩種形式,內容一樣,只是在不同的位置進行配置,例如上面在server.xml中配置的內容,可以在創建一個名為test.xml的文件,將其存放在Tomcat的conf/localhost/test.xml,即上面兩項的第一種情況,這里注意應用的名稱會直接使用文件名,path的配置會被忽略。
嚴格來說,第二種并不能直接替換前面server.xml里的情況,所能解決的是對于webapps目錄內部署應用的額外配置,例如manager這個應用,要增加遠程訪問限制(為什么你的Manager登錄不成功?),就是通過第二種,在META-INF目錄內增加context.xml來實現的。
而實質上這兩種統一稱為Context的描述文件(Context Descriptor)。這些描述文件里包含一些應用對于Context的特定配置,例如配置Session Manager,指定naming Resrouce,定義SessionCookie名稱等。使用描述文件,相當于給Context做了自定義,沒提供描述文件的應用,Tomcat就會直接使用默認值初始化應用。
而且還有一點,使用描述文件定義的應用,會先部署。
下面來看源代碼
源碼
在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);
}
我們看到部署順序:
部署XML描述文件
部署WAR應用
部署解壓的Web應用
其中讀取應用的目錄就是各個Host對應的appBase對應的配置,我們常用的webapps目錄是虛擬主機localhost默認對應的位置。
部署描述符,即第一種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生成那行代碼,是直接使用了文件名進行Context的設置,ContextName我們前面文章看過源代碼,這里配置的就是path,即實際請求的應用名稱。
然后實際部署時,先通過Digester解析文件獲取Context對象,再進行屬性配置,之后的部署流程和其它的一致。
在StandardContext的初始化流程中,會判斷獲取之前設置的configFile對象,不為空會解析文件內容。
而我們上面的第二種方式:為應用提供context.xml,在Tomcat代碼內,稱之為ApplicationContextXml。
這個文件是在第二和第三個部署的時候,解析META-INF目錄下是否包含context.xml,然后設置Context的configFile屬性。初始化Context的時候,會有如下邏輯
if (context.getConfigFile() != null) {
processContextConfig(digester, context.getConfigFile());
}
這個就是前面webappname.xml解析時設置configFile之后走的流程,在ContextConfig中。
這樣一來,我們的自定義配置文件就在Tomcat中生效了。
上述就是小編為大家分享的Tomcat目錄部署與Context描述文件context.xml的示例分析了,如果剛好有類似的疑惑,不妨參照上述分析進行理解。如果想知道更多相關知識,歡迎關注億速云行業資訊頻道。
免責聲明:本站發布的內容(圖片、視頻和文字)以原創、轉載和分享為主,文章觀點不代表本網站立場,如果涉及侵權請聯系站長郵箱:is@yisu.com進行舉報,并提供相關證據,一經查實,將立刻刪除涉嫌侵權內容。