程序从tomcat迁移至websphere的修改

由于客户们使用的web应用服务器采用的软件不一，什么tomcat5,tomcat6,websphere5.1,websphere6.1,weblogic8,等等，而这些软件所采用的标准又不一致，ibm的was连jdk都采用的自己的，痛苦的是开发人员啊。

tomcat下开发一般很少遇到什么问题，而且真正上线时，客户很少采用tomcat,一般都是was(既websphere),这就需要把程序部署到was下。当然，很多不做实事的项目负责人会说这很简单(因为你没做过也不是你去做)，而把这个工作放到开发完之后去转，但实际上，还是有很多地方要注意的，最好在开发前弄清楚，部署的时候会减少很多麻烦。

下面把我的经验列一下：

1、include的文件要注意：

<%@ page contentType="text/html; charset=UTF-8"%>

这个在was5下不能被多次设置，include文件中如果有要去掉,

不过was6.0以上就可以了。

2、web.xml中的serlvet标准

was5.1只支持2.3标准，was6.0以上才可以支持2.4，如果程序需要跨不同版本的应用服务器，最好采用2.3标准.

2.3的开头设置如下：

2.4的如下:

如果你有用spring，那么你肯定比较喜欢如下的配置：

  
   org.springframework.web.context.ContextLoaderListener
  


  contextConfigLocation
  
   /WEB-INF/classes/applicationContext*.xml
  

但是很遗憾的说，在2.3的标准下是不能用的，这个实在让我很郁闷，还好spring还提供一个servlet供初始化

  SpringContextServlet
  
   org.springframework.web.context.ContextLoaderServlet
  
  1

但是这样就不能设置contextConfigLocation参数了(或许有，是我还没找到),这样，如果配置文件有多个，比如：

applicationContext-struts.xml,applicationContext-hibernate.xml等等，

那么我就需要把他们合成一个文件，放到web-infapplicationContext.xml，注意，不是web-infclasses中。

3.ajax调用的编码问题：

如果你有用ajax去传一些中文，那么在从服务器端发往客户端时，你可能会用

response.setCharacterEncoding("GBK")，来解决乱码问题，但是再次很遗憾的说，

这个方法是不被支持的，你可以用：

response.setContentType("text/xml;charset=GBK");

来替代，我也推荐这种方式。另外，request.setCharacterEncoding方法还是可以用的。

4.根据我的尝试，最好还是把servlet-api.jar包放进去，此包可以从tomcat里面找到

5.绝对要使用jdk1.4标准去编译，不是要你使用1.4的jdk,只是把构建的标准改为1.4就可以了。

如果编译不过去，那你就去老老实实改程序吧，不要去浪费时间想什么外门邪道，比如去更改was的jdk等等疯狂举动。

所以，jdk5.0及以后版本中新增的一些新玩意，如果你不能确定客户使用的服务器软件支持的话，最好还是不要使用。

6.不要写文件到服务器，否则在群集部署的时候就会有问题了。