共计 1691 个字符,预计需要花费 5 分钟才能阅读完成。
问题发生背景:
由于公司的 web 环境大都是 tomcat,所以在项目发布出现小问题为了快速解决时常会需要手动增加或修改 war 包解压后的内容。但是在修改时有的 webapps 下除了 war 包解压后的包文件,还会多出一个 ROOT 文件夹,而且开发通常都会告诉我:别忘了修改 ROOT 里面的内容。
为什么呢,为什么还要修改 ROOT 下的内容?
下面先讲解 tomcat 下 webapps 中 ROOT 的作用
tomcat 下 webapps 中 ROOT 目录的作用:
在初学 tomcat 时当部署完 tomcat,我们输入 IP:8080 默认端口时通常会出现一个 tomcat 的欢迎界面,而这个欢迎界面就在 webapps 的 ROOT 中。
一般 tomcat 的访问是 ”IP: 端口 / 包名“ 形式的
但 ROOT 的作用则是省去了包名使得访问 tomcat 的 war 包项目只需要 ”IP: 端口“ 就可以,这可以简化反代的配置。不需要反向代理时写死包名,使得更换项目时不必再对反向代理进行修改。在一定程度上减少了运维人员的工作量。
ROOT 目录是怎么出现的呢
刚开始由于对 tomcat 一无所知,因此对 ROOT 的出现很是困惑,为什么每次发布前我都把 ROOT 删掉,在发布后 ROOT 总是再度出现。之前需要对发布后的项目进行小范围改动时,不知道为什么还要对 ROOT 进行修改。直到现在才明白对发布后的项目修改时为什么一定要修改 ROOT
ROOT 的意义在前面已经说到了,它可以简化访问的 url,同时在项目包名变更时不必对反向代理进行额外的修改。
ROOT 的出现与 conf/server.xml 配置文件有关
在 server.xml 文件中有项额外的配置是
<Context path=
""
reloadable=
"true"
docBase=
"/deploy/to/war"
/>
docBase 可以是 war 包的路径也可以是 war 包解压后的文件夹名的路径
xxx.war 形式
<Context path=”” reloadable=”true” docBase=”/opt/xxx.war” />
例如 xxx.war 在 /opt 下,docBase 可以写成 docBase=”/opt/xxx.war”,此时启动 tomcat,在 engine 的默认 webapps 下会生成一个名为 ROOT 的文件夹,该文件夹内就是 xxx.war 解压后的内容。
通过查看日志可以发现一则信息
DEBUG [localhost-startStop-1] – Published root WebApplicationContext as ServletContext attribute with name [org.springframework.web.context.WebApplicationContext.ROOT]
该信息大意:将 ServletContext 中的定义的包解压后的内容发布到 ROOT 文件夹下。
xxx 文件夹形式
<Context path=”” reloadable=”true” docBase=”xxx” />
注:docBase 有绝对路径跟相对路径之分,相对路径是相对于 engine 引擎定义的 webapps
如果 docBase 指定的路径为 xxx.war 包解压后文件夹的形式,则需要 将 xxx.war 放在 webapps下,其过程大致为:tomcat 先将 xxx.war 解压为 xxx 文件,之后将 xxx 文件夹复制为以 ROOT 为名字的新文件夹。
总结:
tomcat 访问 IP: 端口的方式访问 war 包项目的方式是比较方便的,我也建议这么做。不过发布时记得删除 ROOT 文件夹,否则在你发布后你会发现你这次发布的没有任何变化,若发布后出现小问题需要快速解决,记得是要对 ROOT 下的内容进行修改而不是解压的 war 包内容。
现在我才知道开发通知告诉我的其实只有一半是正确的,那就是 修改 ROOT!。
我所写的不一定全对,不过经过实验验证,目前没发现错误,如果有哪里说的有误欢迎指正。
本文永久更新链接地址:http://www.linuxidc.com/Linux/2017-08/146164.htm