最近項目組做了一個Blog系統（我沒有參與），玩Blog的人都知道，訪問某個Blog的時候，通常的格式是http://host:port/blogxxx，這個blogxxx的路徑在應用部署目錄下實際上是不存在的，只是使用了Filter攔截解釋才得以返回正確的結果。

這個Blog應用在開發環境是WebSphere Application Server 6.1.0.0版本的，一切運行正常。到了生產環境部署的時候是用的WebSphere Application Server 6.1.0.25版本的，訪問Blog的時候就會出現404的錯誤。

一開始以為是應用的問題，仔細檢查了應用之后，感覺問題不在于應用。打開了WAS的Trace看了一下，感覺有點差別：

請求的Blog地址為: http://xxxx.com/Blog/BillyTest

在WAS 6.1.0.0的Trace(真實IP地址替換為0.0.0.0)：

[10-6-25 3:26:45:236 CST] 00000035 WebContainer  3   Looking for vhost with key –> 0.0.0.0:9080/Blog/BillyTest/
[10-6-25 3:26:45:236 CST] 00000035 VirtualHostCo 3   map vHost [0.0.0.0:9080] relativePath [/Blog/BillyTest/]
[10-6-25 3:26:45:236 CST] 00000035 WebContainer  3   request processor handling request --> com.ibm.ws.wswebcontainer.webapp.WebGroup@15de15de
[10-6-25 3:26:45:236 CST] 00000035 WebGroup      3   WebGroup found --> /Blog
[10-6-25 3:26:45:236 CST] 00000035 SRTServletReq 3   getEncodedRequestURI
[10-6-25 3:26:45:236 CST] 00000035 SRTServletReq 3   getEncodedRequestURI uri --> /Blog/BillyTest/
[10-6-25 3:26:45:236 CST] 00000035 SRTServletReq 3   getRequestURI uri --> /Blog/BillyTest/
[10-6-25 3:26:45:236 CST] 00000035 WebApp        3   URI --> /Blog/BillyTest/ handled by WebApp --> XXXXX_BLOG_EAR
[10-6-25 3:26:45:236 CST] 00000035 SRTServletReq 3   getWebAppDispatcherContext
[10-6-25 3:26:45:236 CST] 00000035 SRTServletReq 3   getWebAppDispatcherContext
[10-6-25 3:26:45:236 CST] 00000035 SRTServletReq 3   getWebAppDispatcherContext
[10-6-25 3:26:45:236 CST] 00000035 SRTServletReq 3   resetPathElements
[10-6-25 3:26:45:236 CST] 00000035 SRTServletRes 3   Setting the default response encoding
[10-6-25 3:26:45:236 CST] 00000035 SRTServletReq 3   getWebAppDispatcherContext
[10-6-25 3:26:45:236 CST] 00000035 SRTServletRes 3   _locale: zh_CN
[10-6-25 3:26:45:236 CST] 00000035 SRTServletRes 3   _encoding: ISO-8859-1
[10-6-25 3:26:45:236 CST] 00000035 WebApp        3   RequestProcessor handling request is class com.ibm.ws.wswebcontainer.extension.DefaultExtensionProcessor
[10-6-25 3:26:45:236 CST] 00000035 SRTServletReq 3   getWebAppDispatcherContext
[10-6-25 3:26:45:236 CST] 00000035 SRTServletReq 3   getAttribute name --> javax.servlet.include.request_uri
[10-6-25 3:26:45:236 CST] 00000035 SRTServletReq 3   getWebAppDispatcherContext
[10-6-25 3:26:45:236 CST] 00000035 SRTServletReq 3   getServletPath --> path
[10-6-25 3:26:45:236 CST] 00000035 SRTServletReq 3   getWebAppDispatcherContext
[10-6-25 3:26:45:236 CST] 00000035 SRTServletReq 3   getPathInfo path --> /BillyTest/
[10-6-25 3:26:45:236 CST] 00000035 DefaultExtens 3   handleRequest: servletPath [] pathInfo [/BillyTest/]
[10-6-25 3:26:45:236 CST] 00000035 SRTServletReq 3   getWebAppDispatcherContext
[10-6-25 3:26:45:236 CST] 00000035 WebAppFilterM >  doFilter Entry
[10-6-25 3:26:45:236 CST] 00000035 SRTServletReq 3   getAttribute name --> com.ibm.servlet.engine.webapp.dispatch_nested
[10-6-25 3:26:45:236 CST] 00000035 WebAppFilterM 3   requestURI [/BillyTest/] isInternal [false]
[10-6-25 3:26:45:236 CST] 00000035 LRUCache      >  get Entry
                                 /BillyTest/
[10-6-25 3:26:45:236 CST] 00000035 LRUCache      <  get Exit
[10-6-25 3:26:45:236 CST] 00000035 WebAppFilterC >  _doFilter Entry

可以看到，在最后幾行，請求的URL進入了Filter Chain進行處理了，后續Filter的處理已經省略。

在WAS 6.1.0.25上的Trace(真實IP地址已經替換為0.0.0.0)

[10-6-25 3:02:06:515 GMT+08:00] 00000112 WebContainer  3   Looking for vhost with key –> 0.0.0.0:80/Blog/BillyTest
[10-6-25 3:02:06:515 GMT+08:00] 00000112 VirtualHostCo 3   map vHost [0.0.0.0:80] relativePath [/Blog/BillyTest]
[10-6-25 3:02:06:515 GMT+08:00] 00000112 WebContainer  3   request processor handling request --> com.ibm.ws.wswebcontainer.webapp.WebGroup@52245224
[10-6-25 3:02:06:515 GMT+08:00] 00000112 WebGroup      3   WebGroup found --> /Blog
[10-6-25 3:02:06:515 GMT+08:00] 00000112 SRTServletReq >  getRequestURI [com.ibm.ws.webcontainer.srt.SRTServletRequest@7710771] Entry
[10-6-25 3:02:06:515 GMT+08:00] 00000112 SRTServletReq >  getEncodedRequestURI [com.ibm.ws.webcontainer.srt.SRTServletRequest@7710771] Entry
[10-6-25 3:02:06:515 GMT+08:00] 00000112 SRTServletReq <  getEncodedRequestURI uri --> /Blog/BillyTest Exit
[10-6-25 3:02:06:515 GMT+08:00] 00000112 SRTServletReq <  getRequestURI uri --> /Blog/BillyTest Exit
[10-6-25 3:02:06:515 GMT+08:00] 00000112 WebApp        3   (WEB) URI --> /Blog/BillyTest handled by WebApp --> TJMCC_EIPIV_YYT_BLOG_EAR
[10-6-25 3:02:06:515 GMT+08:00] 00000112 SRTServletReq 3   getWebAppDispatcherContext [com.ibm.ws.webcontainer.srt.SRTServletRequest@7710771]
[10-6-25 3:02:06:516 GMT+08:00] 00000112 SRTServletReq 3   getWebAppDispatcherContext [com.ibm.ws.webcontainer.srt.SRTServletRequest@7710771]
[10-6-25 3:02:06:516 GMT+08:00] 00000112 SRTServletReq 3   getWebAppDispatcherContext [com.ibm.ws.webcontainer.srt.SRTServletRequest@7710771]
[10-6-25 3:02:06:516 GMT+08:00] 00000112 SRTServletReq 3   resetPathElements [com.ibm.ws.webcontainer.srt.SRTServletRequest@7710771]
[10-6-25 3:02:06:516 GMT+08:00] 00000112 SRTServletRes 3   Setting the default response encoding
[10-6-25 3:02:06:516 GMT+08:00] 00000112 SRTServletReq 3   getWebAppDispatcherContext [com.ibm.ws.webcontainer.srt.SRTServletRequest@7710771]
[10-6-25 3:02:06:516 GMT+08:00] 00000112 SRTServletRes 3   _locale: zh_CN
[10-6-25 3:02:06:516 GMT+08:00] 00000112 SRTServletRes 3   _encoding: ISO-8859-1
[10-6-25 3:02:06:516 GMT+08:00] 00000112 WebApp        3   RequestProcessor handling request is class com.ibm.ws.wswebcontainer.extension.DefaultExtensionProcessor
[10-6-25 3:02:06:516 GMT+08:00] 00000112 SRTServletReq 3   getWebAppDispatcherContext [com.ibm.ws.webcontainer.srt.SRTServletRequest@7710771]
[10-6-25 3:02:06:516 GMT+08:00] 00000112 SRTServletReq >  getRequestURI [com.ibm.ws.webcontainer.srt.SRTServletRequest@7710771] Entry
[10-6-25 3:02:06:516 GMT+08:00] 00000112 SRTServletReq >  getEncodedRequestURI [com.ibm.ws.webcontainer.srt.SRTServletRequest@7710771] Entry
[10-6-25 3:02:06:516 GMT+08:00] 00000112 SRTServletReq <  getEncodedRequestURI uri --> /Blog/BillyTest Exit
[10-6-25 3:02:06:516 GMT+08:00] 00000112 SRTServletReq <  getRequestURI uri --> /Blog/BillyTest Exit
[10-6-25 3:02:06:517 GMT+08:00] 00000112 DefaultExtens >  handleRequest : request--->/Blog/BillyTest<--- Entry
[10-6-25 3:02:06:517 GMT+08:00] 00000112 SRTServletReq 3   getAttribute name --> javax.servlet.include.request_uri [com.ibm.ws.webcontainer.srt.SRTServletRequest@7710771]
[10-6-25 3:02:06:517 GMT+08:00] 00000112 SRTServletReq 3   getWebAppDispatcherContext [com.ibm.ws.webcontainer.srt.SRTServletRequest@7710771]
[10-6-25 3:02:06:517 GMT+08:00] 00000112 SRTServletReq 3   getServletPath --> path
[10-6-25 3:02:06:517 GMT+08:00] 00000112 SRTServletReq >  getPathInfo [com.ibm.ws.webcontainer.srt.SRTServletRequest@7710771] Entry
[10-6-25 3:02:06:517 GMT+08:00] 00000112 SRTServletReq 3   getWebAppDispatcherContext [com.ibm.ws.webcontainer.srt.SRTServletRequest@7710771]
[10-6-25 3:02:06:517 GMT+08:00] 00000112 SRTServletReq <  getPathInfo path --> [/BillyTest] Exit
[10-6-25 3:02:06:517 GMT+08:00] 00000112 DefaultExtens 3   handleRequest: servletPath [] pathInfo [/BillyTest]
[10-6-25 3:02:06:517 GMT+08:00] 00000112 DefaultExtens 3   handleRequest stripping leading slashes pathInfo ---> BillyTest
[10-6-25 3:02:06:517 GMT+08:00] 00000112 DefaultExtens 3   file does not exist :/opt/IBM/WebSphere/AppServer/profiles/AppSrv01/installedApps/wasc3Cell01/TJMCC_EIPIV_YYT_BLOG_EAR.ear/TJMCC_EIPIV_YYT_Blog.war/BillyTest
[10-6-25 3:02:06:517 GMT+08:00] 00000112 DefaultExtens 3   isDirectoryTraverse returningfalse , matchstring :/BillyTest
[10-6-25 3:02:06:517 GMT+08:00] 00000112 DefaultExtens 3   FileNotFoundException caught
[10-6-25 3:02:06:517 GMT+08:00] 00000112 SRTServletReq 3   setAttribute name --> com.ibm.ws.webcontainer.filter.filenotfound value --> com.ibm.websphere.servlet.error.ServletErrorReport: SRVE0190E: 找不到文件：/BillyTest [com.ibm.ws.webcontainer.srt.SRTServletRequest@7710771]

從最后一行可以看出，Web容器在Filter作用之前去Web應用所在目錄下查找/BillyTest目錄，結果發現沒有找到，所以就直接返回了404的響應給瀏覽器。

從上面的Trace對比，懷疑問題出在WAS下版本的行為變化上，查閱一下IBM的文檔，找到如下一個解釋：

在WebSphere 6的某些版本中，Web容器在查找用戶請求的資源之前，不會調用用戶自行設定的Filter。所以在上面的例子中，由于所請求的/BillyTest資源并不是實際存在的，所以未經過應用Filter處理就拋出了FileNotFoundException。要想改變服務器的這種行為，需要為Web容器設置自定義參數：com.ibm.ws.webcontainer.invokeFiltersCompatibility，將其設置為”true”

登錄WAS Admin，服務器>應用服務器>your_server_name>Web容器設置>Web容器>定制屬性，點擊“新建”，加入一個自定義屬性：

名稱：com.ibm.ws.webcontainer.invokeFiltersCompatibility

值：true

配置之后，重新啟動則應用運行正常。

經過這次的問題處理，感覺測試環境和生產環境應該盡可能的使用同樣版本的平臺和產品，否則會在上線的時候給你帶來意外的驚喜。

關于這個問題原文地址在：

http://www-01.ibm.com/support/docview.wss?rs=180&uid=swg1PK31377