如何修改Tomcat的默认项目发布路径
tomcat默认的项目发布目录是/webapp/ROOT，如果想自定义发布目录，应该怎么办呢？
修改配置文件
首先，修改$tomcat/conf/server.xml文件。
在server.xml文件中，有一段如下：
<engine name="Catalina" defaultHost="localhost"> <host name="localhost" appBase="webapps" unpackWARs="true" autoDeploy="true" xmlValidation="false" xmlNamespaceAware="false"> <host> </engine>
在标签之间添加上：
<Context path="" docBase="myworkspace" debug="0" reloadable="true" />
path是说明虚拟目录的名字，如果你要只输入ip地址就显示主页，则该键值留为空； docBase是虚拟目录的路径，它默认的是$tomcat/webapps/ROOT目录，现在我在webapps目录下建了一个myworkspace，即为我的工作目录。
踩过的坑
光看上面的过程，似乎非常顺畅，但世上的事总是不会那么顺利的。下面列举几个我踩过的坑。
3.1、Windows系统下，redeploy过程无法删除旧项目的目录
报错信息在$TOMCAT_HOME/logs下的catalina日志文件中，如下：
信息: Undeploying context [/web-loab]
十月 11, 2014 3:52:26 下午 org.apache.catalina.startup.ExpandWar deleteDir
严重: [D:\tomcat\apache-tomcat-7.0.56\webapps\web-loab\WEB-INF] could not be completely deleted. The presence of the remaining files may cause problems
大概是因为Tomcat还在使用这个目录，无法删除，必须修改$TOMCAT_HOME/conf/context.xml：
<Context antiJARLocking="true" antiResourceLocking="true">
Servelt.class offending
这个问题应该不属于本文主题范畴了，但可能因为这个导致Web项目启动起来却无法访问，报错信息如下：
十月 11, 2014 3:46:29 下午 org.apache.catalina.loader.WebappClassLoader validateJarFile
信息: validateJarFile(D:\tomcat\apache-tomcat-7.0.56\webapps\web-loab\WEB-INF\lib\servlet-api-6.0.29.jar) - jar not loaded. See Servlet Spec 3.0, section 10.7.2. Offending class: javax/servlet/Servlet.class
原因是webapps目录下的某个Web项目的WEB-INF/lib目录下有servlet-api.jar，删除之，并在pom.xml中指定servelt-api.jar的scope为provided：
<dependency> <groupId>org.apache.tomcat</groupId> <artifactId>servlet-api</artifactId> <version>6.0.29</version> <scope>provided</scope> </dependency>
版本问题
确保Web项目的Java Build Path使用的JDK版本、Java Compiler的编译JDK版本以及Project Facets里的Java版本一致。
如果用的Tomcat6，则pom.xml中配置tomcat6-maven-plugin，如果用的tomcat7则用tomcat7-maven-plugin。或者默认用tomcat-maven-plugin。
有关使用Tomcat Ｍaven插件部署项目的一些建议
这种方案能够实现持续快捷部署。但它有一些局限性：
-
要求从本地开发环境能直接访问Tomcat服务器所在网段
-
不能保留历史部署包
因此初步建议只在开发环境使用这种部署方式，并且结合SVN、Git等版本控制软件做两个内部约定：
-
所有可部署版本代码都必须先签入一个名为deploy-xx的分支，xx表示当前可部署版本，deploy分支代码必须保证是可以部署的代码，然后切到deploy-xx分支再部署项目
-
以后增加了新功能，则需新建另一个deploy分支，并增大版本号。这样可以利用版本控制软件帮我们保留各个历史可部署代码（解决了上面提到的第二个局限性）。尤其是多个项目集成时，最好保证每一次集成时各个项目的deploy分支带的版本后缀相同。这样可以方便各个项目代码集体回滚
