tomcat 6中context.xml的加載順序 (轉)

    在eclipse裏修改了META-INF/context.xml文件後，在eclipse中，將tomcat重啓後，修改的地方不起做用，最後在tomcat的目錄下找到了緣由，有多是個小白的問題，不過仍是記錄如下，以防有其餘小白遇到跟我同樣的問題。

    tomcat在初次加載項目時，會在tomcat目錄\conf\Catalina\localhost下生成一個「項目名.xml」，我在打開以後發現裏面就是原來的context.xml中的內容。


解決辦法：

    將tomcat目錄\conf\Catalina\localhost下生成的「項目名.xml」，刪除掉，從新啓動，就會將最新修改的context.xml文件生成到這個目錄下。

轉載一篇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的錯誤。