由于客户们使用的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.不要写文件到服务器，否则在群集部署的时候就会有问题了。
收起