tomcat 6中context.xml的加载顺序

死siua11

　　今天需要在另一台机器上重新部署系统，重新设置db的连接池。当我把tomcat拷贝到那台机器，并且修改META-INF\context.xml，然后重新启动tomcat，但发现系统连接的仍然是老的db。再次检查了META-INF\context.xml文件，确信了这个文件已经正确设置db连接了，这也说明这个文件并没有真正起作用。查看了tomcat下conf\context.xml也没有设置db的连接池。那是哪个文件在起作用呢？折腾了办法，后来发现tomcat在conf\Catalina\localhost下生成了一个和原来META-INF\context.xml相同内容的文件，怀疑一定是这个文件在起作用？删除conf\Catalina\localhost目录，重启tomcat，问题消失。
　　转载一篇tomcat加载类的顺序：
　　bin：存放启动和关闭tomcat的脚本文件； 
　　/conf：存放tomcat的各种配置文件，比如：server.xml 
　　/server/lib：存放tomcat服务器所需要的各种jar文件（jar文件只可被tomcat 服务器访问） 
　　/server/webapps：存放tomcat自带的两个web应用：admin应用和manager应用。 
　　/common/lib：存放tomcat服务器以及所有web应用都可以访问的jar文件夹（web和tomcat服务器都可访问此jar） 
　　/shared/lib：存放web都可访问的jar文件。（可以被所有的web访问，但不能被tomcat访问） 
　　/logs：存放tomcat的日志文件 
　　/webapps：当发布web应用时，默认情况下把web应用文件放于此目录下 
　　/work：tomcat把由jsp生成的Servlet放于此目录 
　　另：在web应用中，WEB-Inf目录下，也可以建立lib子目录，在此子目录下可以存放各种jar文件，这些jar文件只能被当前web应用访问。其中，在web-inf目录下的lib与classes目录，Tomcat类装载器先装载classes目录下的类，再装载lib目录下的类。因为类同名时，classes优先。 
　　其中jsp运行时，查找class的顺序为：项目文件夹（WEB-INF\lib）===》容器文件夹（tomcat\common\lib）==》jdk文件夹（jdk\jre\lib\ext） 
　　Tomcat的class加载的优先顺序一览 
　　1.最先是$JAVA_HOME/jre/lib/ext/下的jar文件。 
　　2.环境变量CLASSPATH中的jar和class文件。 
　　3.$CATALINA_HOME/common/classes下的class文件。 
　　4.$CATALINA_HOME/commons/endorsed下的jar文件。 
　　5.$CATALINA_HOME/commons/i18n下的jar文件。 
　　6.$CATALINA_HOME/common/lib 下的jar文件。 
　　（JDBC驱动之类的jar文件可以放在这里，这样就可以避免在server.xml配置好数据源却出现找不到JDBC Driver的情况。） 
　　7.$CATALINA_HOME/server/classes下的class文件。 
　　8.$CATALINA_HOME/server/lib/下的jar文件。 
　　9.$CATALINA_BASE/shared/classes 下的class文件。 
　　10.$CATALINA_BASE/shared/lib下的jar文件。 
　　11.各自具体的webapp /WEB-INF/classes下的class文件。 
　　12.各自具体的webapp /WEB-INF/lib下的jar文件。 
　　class的搜寻顺序如下 
　　------------- 
　　/WEB-INF/classes of your web application 
　　/WEB-INF/lib/*.jar of your web application 
　　$CATALINA_HOME/common/classes 
　　$CATALINA_HOME/common/endorsed/*.jar 
　　$CATALINA_HOME/common/i18n/*.jar 
　　$CATALINA_HOME/common/lib/*.jar 
　　$CATALINA_BASE/shared/classes 
　　$CATALINA_BASE/shared/lib/*.jar 
　　-------------- 
　　因此放在不同webapp里的class文件，会被classloader加载成不同的实例。 
　　例如假设下面两个不同内容的class。分别放在不同的webapp的class目录下。 
　　package com.lizongbo; 
　　public class TestClass { 
　　private String NAME="lizongbo"; 
　　} 
　　package com.lizongbo; 
　　public class TestClass { 
　　private String NAME="li_zongbo"; 
　　} 
　　在不同的webapp得到的com.lizongbo.NAME结果是不同的，且互不影响。 
　　但是注意，以下包名开头的class例外： 
　　javax.* 
　　org.xml.sax.* 
　　org.w3c.dom.* 
　　org.apache.xerces.* 
　　org.apache.xalan.* 
　　ps,注意.在各个jar中的\META-INF\MAINFEST.MF文件里Class-Path键值对，也会提供jar的加载优先顺序。 
　　例如某jar的MAINFEST.MF内容如下： 
　　Manifest-Version: 1.0 
　　Created-By: lizongbo 
　　Class-Path: commons-beanutils.jar 
　　Class-Path: commons-collections.jar 
　　Class-Path: commons-dbcp.jar 
　　Class-Path: commons-digester.jar 
　　Class-Path: commons-logging.jar 
　　Class-Path: commons-pool.jar 
　　Class-Path: commons-services.jar 
　　Class-Path: commons-validator.jar 
　　Class-Path: jakarta-oro.jar 
　　Main-Class: com.lizongbo.MyTestClass 
　　那么在加载这个jar的时候，会先在此jar所在目录下依次先加载commons-beanutils.jar，commons-collections.jar。。。等jar文件。 
　　在不同的地方放置jar和class可能会产生意想不到的后果,，尤其是不同版本的jar文件，因此在实际应用部署web应用时候要特别留心. 
　　例如 使用javamail常见的一个出错信息: 
　　javax.mail.NoSuchProviderException: No provider for smtp 
　　其真实原因就很可能如下: 
　　在不同的加载jar的目录下放置了不同版本的mail.jar,比如一个是javamail1.3.1的mail.jar 
　　在D:\jakarta-tomcat-5.5.8\common\lib下,而另外一个是javamail1.3.2的mail.jar在 
　　D:\jakarta-tomcat-5.5.8\webapps\lizongbo\WEB-INF/lib下, 
　　那么lizongbo这个webapp中使用到javamail进行邮件发送的时候，便会出现No provider for smtp的错误。