tomcat7.0中外置的Context配置

在D:\apache-tomcat-7.0.52\conf\Catalina\localhost这个目录下新建一个XML文件,文件名称可以为ROOT.xml,这样访问的URL就是http://localhost:8080/index.jsp就可以访问到你的项目,如果文件名称为myweb (注意此文件名将作为Context中的path,不管文件里的path怎么设置也无效),这样访问的URL就是http://localhost:8080/myweb/index.jsp
[html]  view plain  copy
 
  1. xml version='1.0' encoding='utf-8'?>  
  2. <Context crossContext="true"  
  3.   privileged="true"  
  4.   path=""  
  5.   docBase="E:\\workspaces\\EclipseEE4.4\\DaseLab\\WebContent"  
  6.   reloadable="false"  
  7.   unpackWAR="true"  
  8.   cachingAllowed="true"  
  9.   cacheMaxSize="1024"  
  10.   >Context>  
path 指定访问该Web应用的URL入口,如果path为空字符串(""),这个context是所属Host的缺省(默认)web应用,用来处理不能匹配任何context path的请求。
docBase 指定Web应用的文件路径,可以给定绝对路径,也可以给定相对于的appBase属性的相对路径,如果Web应用采用开放目录结构,则指定Web应用的根目录,如果Web应用是个war文件,则指定war文件的路径。
具体是主目录的配置还是虚拟目录的配置取决于path的值。另外主目录文件名必须是ROOT.xml(root大写),而虚拟目录的文件名称为小写,名称任意,文件的名称就是你访问web项目时的根路径,例如: 
 
 
以上则定义了一个名为:mysystem的虚拟目录,同时要将以上文本保存为mysystem.xml文件。 

crossContext="true" ,是允许应用通过 ServletContext.getContext() 去拿到一个通往别的应用 request dispatcher 。当然了,这种方法无法跨越现在 Tomcat 支持的虚拟主机界限。也就是说,能够穿透访问的,必须是和当前应用在一个 之中的应用。

privileged="true" 意味着 Tomcat 自身的应用,比如· Tomcat Manager ,可以被当前这个应用访问。根据官方文档的解释,这个机理是改变应用的类加载器为 Server class loader 。我想,这种改变,会令应用程序发现 Tomcat 本身的类,都能够从应用自己的类加载器上寻找到。从而实现对 Tomcat 自身应用程序方法的调用。

path 和 docBase 不用多说,都要指定这二个属性的。其中 docBase 可以是目录也可以是结构完整的 .war 文件。

reloadable="true" 意味着 Tomcat 将提供对应用类路径( /WEB-INF/classes/ 和 /WEB-INF/lib/ )的监测。当这里边有内容改变并且其类已经被爪哇虚拟机(JVM)加载的时候,Tomcat 可以自行重新加载此类。不过此功能对 Tomcat 的稳定服务影响不小,调试环境可以使用,生产环境还是算了吧——当然,这只是我的个人建议。

unpackWAR 就如字面意思,unpackWAR="true" 意味着 Tomcat 会保存 .war 包的解压结果,然后直接对解压结果进行运行。我个人认为,考虑到爪哇虚拟机的类加载机制,每个类都仅加载一回,但是页面内容却没有类似的有效缓存,所以 .war 还是解压执行的比较好。而且日志也将造成 unpackWAR="false" 形同灾难。

cachingAllowed="true" 意味着开启了 Tomcat7 的静态缓存功能。静态文件包括 JavaScript 程序、图片声音等允许网络访问的文件以及 HTML 页面。


以上目录配置好后就可以按以下地址访问了: 
http://127.0.0.1:8080/(访问主目录) 
http://127.0.0.1:8080/mysystem (访问名为mysystem的虚拟目录)

你可能感兴趣的:(Java应用)