在单独的tomcat中，在service.xml里面可以配置context，也就是说让哪个url对应哪个应用程序。比如：http://localhost/abc 对应于 文件系统中的某个节点c:kkkcba。而且在tomcat环境里，在webapps目录下，你放置一个webapp，比如abc.war，则自动展开之后变成abc目录。
相对而言，与jboss集成的tomcat配置起来没有单独的tomcat来的灵活，因为好多配置权转移到了jboss的其他配置文件里去了，比如conf/jboss-service.xml.与jboss集成的tomcat表现为jboss下的一个应用程序，在deploy目录下的jbossweb-tomcat41.sar。你进入这个目录之后，在META_INF目录下会发现一个jboss-service.xml，仔细观察它的内容，和单独tomcat的serive.xml类似。但是你会发现好多参数都是无效的，比如context配置和security配置等。
jboss conf/jboss-service.xml可以让你设定除了deploy目录之外的其他发布地点，并且jboss将war文件展开时和tomcat完全不一样，他展开到一个tmp目录里面，并且每次展开时名称会发生变化。这种方式对于依赖于web应用程序目录结构的程序来说非常不方便，比如你在一个固定的目录里保存用户上传的文件，然后通过文件目录去访问它，就会发生找不到的情况，因为每一次发布之后，目录名变了。
当然，你可以直接将已经展开的war文件放在deploy目录下，不过你的目录名称也必须以.war结尾。
j2ee应用程序，可以在deployment description里面设定context path.比如abc.ear，在它的META_INF目录里的application.xml可以指定
<model>
<web>
<web-url>abc.war</weburl>
<context-root>/</context-root>
</web>
</model>
从以上也可以看出，app server环境中，保存context mapping 的变量就像操作系统里的环境变量一样是全局性的，不管你通过app server体统的何种方法获得一个context，如果发生重复，都会提示或报错。 
|
本类阅读TOP10