我们的项目在研发阶段，一般情况下都是使用tomcat，但是项目部署到客户现场之后，我们的mantis就不断的收到回馈的“莫名其妙”的BUG list，之所以说是“莫名其妙”，是指：不同的容器设置与处理方法不同，导致一些功能逻辑在此容器下正常，换个容器就出问题的现象。

　　我也是初学者，只是看到许多人也有像我这样痛苦的问题，所以经艾依然大哥的同意与支持，记在这里，也欢迎各位同道不断提出各自经验，交流学习。

  　格式如下：

　　（1）【现象描述】：tomcat下getRemoteHost可以获取客户端IP，但是放到was下则是主机名。

　　【问题分析】：tomcat下getRemoteHost默认是获取客户端IP，但是规范的使用是使用getRemoteAddr方法获取IP地址。

　　【差异总结】：如果你想在tomcat使用getRemoteHost方法下获取主机名，那么请修改tomcat：server.xml文件中设置enableLookups=”true”。TOMCAT的一些版本默认getRemoteHost是获取客户端IP，因此导致一些程序员产生了错觉。我们应该使用规范的getRemoteAddr方法获取客户端IP地址。

　　（2）【现象描述】：tomcat下读取文件没有问题，但是移到was上就不能正确读取文件了。

　　【问题分析】：tomcat对文件路径的处理与was是不一样的。

　　【差异总结】：有的时候你必须输出一些路径信息以供测试。因为你不知道哪个容器支持什么类型的文件读写路径，你应该根据测试输出的路径信息，不断的拼凑路径的字符串，甚至在极端情况下你可能需要为每一个容器写一个读取路径处理方法。

　　（3）【现象描述】：sun的jdk与IBM JDK差异

　　【问题分析】：大多的现场问题都是由它们之间的差异引起的，我没有办法告诉你具体的差异~~ 这里只能谈感觉：IBM的JDK要严谨一些，对于tomcat的一些问题也是这样的。

　　【差异总结】：建议如果现场会大量使用was，那么建议研发、测试的时候也使用IBM的jdk，以及使用was部署测试。这样会避免许多问题。因为IBM下的JDK开发的程序放到TOMCAT下大多没有问题，反之则郁闷多多。这算不算“向下兼容”？~  呵·~

　　（4）【现象描述】：tomcat下没事，其他容器出现乱码问题。

　　【问题分析】：tomcat没有问题 说明语句语法都过得去。首先使用常见的编码过滤机制(EncodingFilter)，然后在was的控制台中将设置编码(论坛上说的很多了，这里就不说了)。如果使用了ajax的话(如：某些表单组件)，还需针对js的提交时做编码转换处理，否则js提交上去的也是乱码。还有jsp中这样写：pageEncoding=”UTF-8″。不要写成UTF8或者小写utf。

　　【差异总结】：乱码问题确实是个大问题，并且在现场如果无法调试的情况下，问题很难定位。我们一个项目现场就曾经出过这样的问题：搜索一个资源，英文搜索词都没问题，中文的资源就搜索不到，后来现场调试了才知道，中文搜索的都是“???”。呵~~ 最终定位是js异步提交乱码。

　　（5）【现象描述】：ClassLoader导致的文件路径问题。

　　【问题分析】：我们通常写类似于这样的代码：

ClassLoader classLoader = Thread.currentThread().getContextClassLoader();
classLoader.getResourceAsStream(“myPropFile.properties”);

　　但是，在WAS下getResourceAsStream方法并没有如我们所愿的返回文件的InputStream，在这种情况下，我们不得不使用InputStream inStream=new FileInputStream(path/+”myPropFile.properties”);
复制代码的形式来处理这个配置文件了。

　　【差异总结】：无疑，ClassLoader这种相对于基本语法来讲，更涉及底层实现，所以每个容器存在差异也很容易理解了。

　　（6）【现象描述】：el表达式tomcat下正常，websphere出现语法错误。

　　【问题分析】：仔细查看el表达式，并不符合规范书写方式，将表达式调整为规范书写格式后was才通过。

　　【差异总结】：was7.0以及其以前版本不支持书写不够严谨的el表达式，在7.0以后的版本中才对此放宽检查。