如何修改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:	omcatapache-tomcat-7.0.56webappsweb-loabWEB-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:	omcatapache-tomcat-7.0.56webappsweb-loabWEB-INFlibservlet-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分支带的版本后缀相同。这样可以方便各个项目代码集体回滚