重庆分公司,新征程启航

为企业提供网站建设、域名注册、服务器等服务

Tomcat目录部署与Context描述文件context.xml的示例分析

这期内容当中小编将会给大家带来有关Tomcat目录部署与Context描述文件context.xml的示例分析,文章内容丰富且以专业的角度为大家分析和叙述,阅读完这篇文章希望大家可以有所收获。

专注于为中小企业提供成都网站建设、成都网站设计服务,电脑端+手机端+微信端的三站合一,更高效的管理,为中小企业济源免费做网站提供优质的服务。我们立足成都,凝聚了一批互联网行业人才,有力地推动了上千多家企业的稳健成长,帮助中小企业通过网站建设实现规模扩充和转变。

在Web应用开发完毕后,一些项目有时候采用目录部署的形式,而且是在server.xml中增加Context配置的形式,例如下面这种形式:

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

但是官方并不鼓励这样配置,可以通过两种在外部文件配置的形式,不影响Tomcat主配置来实现同样的效果。

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

  2. $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);

}

我们看到部署顺序:

  1. 部署XML描述文件

  2. 部署WAR应用

  3. 部署解压的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的示例分析了,如果刚好有类似的疑惑,不妨参照上述分析进行理解。如果想知道更多相关知识,欢迎关注创新互联行业资讯频道。


文章题目:Tomcat目录部署与Context描述文件context.xml的示例分析
转载注明:http://cqcxhl.com/article/ipoops.html

其他资讯

在线咨询
服务热线
服务热线:028-86922220
TOP