最近项目组做了一个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