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