不要把第三方jar包放到容器的lib中,把容器不提供的第三方jar打包到項目中,容器提供的jar就不打包到jar包中。項目運行時,會先檢測項目自己打入的jar包,而後再去容器的lib下面尋找jar包。html
爲何不建議把第三方jar包放到容器中呢?java
由於像common\lib下的包是相對很通用又穩定的包,若是你把你這幾個工程共用的幾個相同包放進來 ,必定時間看起來是文件少了很多 ,但未來需求的變化,可能有的工程 須要比較新版本LIB包,而一些工程 又沒有需求或升級的要求 ,還只是要老版本的LIB包,同時新版本的lib包又依賴一些其餘的包,並得刪除掉一些若是放進去會產生錯誤的包。返正就是包的依賴比較麻煩。你可能只考慮到一個工程 ,而另外一個工程 沒考慮到時就麻煩了。。。
還有,不一樣的中間件,classloader的加載順序 還不同
tomcat,jetty,jboss,websphere,weblogic等 可能會有一些地方不一樣,因此能部署到TOMCAT上的工程,不必定把整個WAR包放到JBOSS下就能正常跑起來,(雖然jboss是基於tomcat)web
像tomcat
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的搜尋順序以下:
-------------
Bootstrap classes of your JVM
System class loader classses (described above)
/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
在weblogic中的classloader有5個層次,從高到低排:
a. jdk
b. jdk ext
c. system classpath
d. ( APP-INF/classes and APP-INF/lib )
e. ( WEB-INF/classes and WEB-INF/lib )
Tomcat與Weblogic有些地方是相反的:對於運行在 Java EE 容器中的 Web 應用來講,類加載器的實現方式與通常的 Java 應用有所不一樣。不一樣的 Web 容器的實現方式也會有所不一樣。以 Apache Tomcat 來講,每一個 Web 應用都有一個對應的類加載器實例。該類加載器也使用代理模式,所不一樣的是它是首先嚐試去加載某個類,若是找不到再代理給父類加載器。這與通常類加載器的順序是相反的。這是 Java Servlet 規範中的推薦作法,其目的是使得 Web 應用本身的類的優先級高於 Web 容器提供的類。這種代理模式的一個例外是:Java 核心庫的類是不在查找範圍以內的。這也是爲了保證 Java 核心庫的類型安全。tomcat
參考文章:安全
Weblogic與Java類加載器原理試驗解析webapp