没有更多推荐了，
不良信息举报
举报内容：
web.xml文件在websphere中会有两个地方存储
举报原因：
原文地址：
原因补充：
最多只允许输入30个字
加入CSDN，享受更精准的内容推荐，与500万程序员共同成长！但是最近迁移到 websphere 6.1.0.3了，出现许多问题，现在拿出来，整理与大分享
1. 在迁移过程中，出现的第一个导常：“java.lang.IllegalStateException: Cannot initialize context because there is already a root application context present - check whether you have multiple ContextLoader* definitions in your web.xml!”。造成这个异常的原因，是有我web.xml文件有两处同代码，都对org.springframework.web.context.ContextLoader上下文进行了加载，于量在spring加载时，就会报错，对于spring来讲，不允许加载两个上下引用，关于这点，大概可以参考org.springframework.web.context.ContextLoaderListener源码就知道怎么回是了！
2.spring配置文件，出错会报“ nested exception is org.xml.sax.SAXParseException: cvc-elt.1：找不到元素“beans”的声明。”,解决办法我参考了论坛中《websphere 中 spring 的问题》一文，现在将原因引入进来，供大家参考：
spring配置文件
引入DTD这种方式在websphere 6.1 下不成功，必须改成 使用schema这种方式。
&?xml version="1.0" encoding="UTF-8"?&
&!DOCTYPE beans PUBLIC "-//SPRING//DTD BEAN 2.0//EN" "http://www.springframework.org/dtd/spring-beans-2.0.dtd"&
&beans default-autowire="byName"&
&?xml version="1.0" encoding="UTF-8"?&
xmlns="http://www.springframework.org/schema/beans"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.springframework.org/schema/beans "
default-autowire="byName"&
default-autowire="byName"&
3.在webm.xml中采用DTD 2.4规范中加载spring的话，必须使用以下方式：
&servlet-name&SpringContextServlet&/servlet-name&
&servlet-class&
org.springframework.web.context.ContextLoaderServlet
&/servlet-class&
&load-on-startup&1&/load-on-startup&
&/servlet&
4.在我迁移过程中，还遇到这样一个比较头痛的问题，搞好几天才找到问题：“servlet debugjsp 抛出的 init() 异常：java.lang.ClassCastException: com.ibm.ws.classloader.CompoundClassLoader incompatible with java.net.URLClassLoader”
第一，就是应用程序jar类加载机制与webshere类加载机制冲突造成，关于这点解决办法，就是更改webshere 服务
器设置或 应用程序的设置。一般情况不建议不更改webshere的设置，至于如何修改设置类加载顺序，可以与论贴，很简单的，所以在不此不做详细描述。
第二种情况比较麻烦，就是工程中存在jar冲突，造成上面的异常，解决的办法就是将简化web.xml，逐个加载自己需要的模块，就可以找问题的原因，我当时解决这个问题，就是这样，一次次改，最终发现在web.xml这段代码在加载jar时,造在上面的异常，以下是代码片断
&servlet-name&debugjsp&/servlet-name&
&description&Added by JBuilder to compile JSPs with debug info&/description&
&servlet-class&org.apache.jasper.servlet.JspServlet&/servlet-class&
&init-param&
&param-name&classdebuginfo&/param-name&
&param-value&true&/param-value&
&/init-param&
&load-on-startup&3&/load-on-startup&
&/servlet&
在自己工程下 compiler.jar
jasper-runtime.jar 存在两个jar ,至此，根本原因找到，因为在web.xml 配置了那段代码
造成应用程序加载了
compiler.jar
jasper-runtime.jar
两个jar包，删除多余代码和jar包，问题即解决。
5.在webshere6.1中对web.xml有严格的语法检测，,一定要按照dtd规范来写，而tomcate在这点比较松，所以在布署的时候，需要注意一下（webshere6.1 支持DTD 2.3 DTD2.4,webshere5 支持2.3
按以下元素顺&context-param&、&filter&、&list&、&servlet&、&servlet-mapping&，具体参考DTD规范
6.大家在打成jar时，建议用ibm jdk1.5，不要sun jdk ,原因是保持兼容性
7.关于tomcate迁移webshere其他的问题，可以参考这篇文章《程序从tomcat迁移至websphere的修改》，另外有问题
--------------------------------------------------------------------------------------
程序从tomcat迁移至websphere的修改
由于客户们使用的采用的不一，什么5,tomcat6,websphere5.1,websphere6.1,8,等等，而这些软件所采用的标准又不一致，ibm的was连jdk都采用的自己的，痛苦的是人员啊。tomcat下开发一般很少遇到什么问题，而且真正上线时，客户很少采用tomcat,一般都是was(既websphere),这就需要把到was下。当然，很多不做实事的负责人会说这很简单(因为你没做过也不是你去做)，而把这个工作放到开发完之后去转，但实际上，还是有很多地方要注意的，最好在开发前弄清楚，部署的时候会减少很多麻烦。下面把我的列一下：1、include的要注意：
&%@ page contentType="text/ charset=UTF-8"%&
这个在was5下不能被多次，include文件中如果有要去掉,不过was6.0以上就可以了。2、web.中的serlvet标准was5.1只支持2.3标准，was6.0以上才可以支持2.4，如果程序需要跨不同版本的应用器，最好采用2.3标准.2.3的开头设置如下：
&?xml version="1.0" encoding="UTF-8"?&
&!DOCTYPE web-app PUBLIC "-//Sun Microsystems, Inc.//DTD Web
2.3//EN" "http://java.sun.com/dtd/web-app_2_3.dtd"&
2.4的如下:
&?xml version="1.0" encoding="UTF-8"?&
&web-app xmlns="http://java.sun.com/xml/ns/j2ee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" version="2.4"
xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee
http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd"&
如果你有用，那么你肯定比较喜欢如下的配置：
&listener&
&listener-class&
org.springframework.web.context.ContextLoaderListener
&/listener-class&
&/listener&
&context-param&
&param-name&contextConfigLocation&/param-name&
&param-value&
/WEB-INF/classes/applicationContext*.xml
&/param-value&
&/context-param&
但是很遗憾的说，在2.3的标准下是不能用的，这个实在让我很郁闷，还好spring还提供一个servlet供初始化
&servlet-name&SpringContextServlet&/servlet-name&
&servlet-class&
org.springframework.web.context.ContextLoaderServlet
&/servlet-class&
&load-on-startup&1&/load-on-startup&
&/servlet&
但是这样就不能设置contextConfigLocation了(或许有，是我还没找到),这样，如果配置文件有多个，比如：applicationContext-struts.xml,applicationContext-hibernate.xml等等，那么我就需要把他们合成一个文件，放到web-inf\applicationContext.xml，注意，不是web-inf\classes中。 3.ajax调用的编码问题：如果你有用ajax去传一些，那么在从服务器端发往时，你可能会用response.setCharacterEncoding("GBK")，来问题，但是再次很遗憾的说，这个方法是不被支持的，你可以用：response.setContentType("text/charset=GBK");来替代，我也推荐这种方式。另外，request.setCharacterEncoding方法还是可以用的。4.根据我的尝试，最好还是把servlet-api.jar包放进去，此包可以从tomcat里面找到5.绝对要使用jdk1.4标准去编译，不是要你使用1.4的jdk,只是把构建的标准改为1.4就可以了。如果编译不过去，那你就去老老实实改程序吧，不要去浪费想什么外门邪道，比如去更改was的jdk等等疯狂举动。所以，jdk5.0及以后版本中新增的一些新玩意，如果你不能确定客户使用的服务器软件支持的话，最好还是不要使用。6.不要写文件到服务器，否则在群集部署的时候就会有问题了。
一杯白开水w
浏览: 154733 次
来自: 北京
总结的很好啊
(window.slotbydup=window.slotbydup || []).push({
id: '4773203',
container: s,
size: '200,200',
display: 'inlay-fix'websphere 中文乱码问题_百度知道
websphere 中文乱码问题
项目部署在TOMCAT下是正常的.文件全部采用UTF-8编码.是SSH架构的
全部JSP文件都已设置&%@ page contentType=&text/charset=UTF-8&%&
部署到WEBSPHERE7,8.5时,都会出现中文乱码问题.
WAS中JVM设定的 -Ddefault.client.encoding=GBK -Dfile.encoding=...
我有更好的答案
你的设置混合了GBK和UTF-8，这有问题的。你首先把WAS参数里全部都用UTF-8再试试
全部设置成了UTF-8也不行呢...
我以前也遇到过这种问题，想要全局的去处理，没找到办法。
为您推荐：
其他类似问题
websphere的相关知识
换一换
回答问题，赢新手礼包
个人、企业类
违法有害信息,请在下方选择后提交
色情、暴力
我们会通过消息、邮箱等方式尽快将举报结果通知您。从 Tomcat 再到使用 Webshpere Application Server (WAS) 不光金钱上付出太多(这当然不用我操心)，精力上也费神的多，不过收获也不少，特别是商业产品在处理大用户量的并发访问能力是 Tomcat 无法比的。这里记述一个使用 WAS 给应用打补丁时遇到的问题--要更新哪一个 web.xml。
为便于描述，我们假设已在 WAS 下部署了一个名叫 Prod.war 的包(你也可以部署一个 ear 包，部署的 ear 包后的目录名更明确一些)，WAS 的安装目录表示为 WAS_HOME，WAS 所在的主机名为 unmi，那么 Prod.war 部署后所在的目录就是
WAS_HOME/installedApps/unmi/Prod_war.ear/Prod.war
用过 WAS 的人都知道，如果是部署后要给应用打补丁的话，和 Tomcat 下的应用一样，也是把类或 JSP 拷到如上相应的目录中就行了，换了类，WAS 会自动重新加载。
可偏偏有一次打补丁，有个同事加的是一个 Servlet 类，如 com.unmi.ReportServlet，并在 web.xml 对这个 Servlet 作为相应的配置
&servlet&&&&
&&& &servlet-name&ReportServlet&/servlet-name&&&&
&&& &servlet-class&com.unmi.ReportServlet&/servlet-class&&&&
&/servlet&&&&
..........................................................................................&&&
&servlet-mapping&&&&
&&& &servlet-name&ReportServlet&/servlet-name&&&&
&&& &url-pattern&/ReportServlet&/url-pattern&&&&
&/servlet-mapping&&
&&& &servlet-name&ReportServlet&/servlet-name&
&&& &servlet-class&com.unmi.ReportServlet&/servlet-class&
&/servlet&
..........................................................................................
&servlet-mapping&
&&& &servlet-name&ReportServlet&/servlet-name&
&&& &url-pattern&/ReportServlet&/url-pattern&
&/servlet-mapping&
然后把 web.xml 拷贝到 WAS_HOME/installedApps/unmi/Prod_war.ear/Prod.war/WEB-INF/ 中，再把 ReportServlet.class 拷到 WAS_HOME/installedApps/unmi/Prod_war.ear/Prod.war/WEB-INF/classes/com/unmi/ 目录中。
然后无论怎么重启应用还是应用服务器，通过 /ReportServlet 的 URL 总是 404 Not Found，没法进入到 com.unmi.ReportServlet，一时有些不知所措，过后到 WAS 管理控制台下看看该应用的 Web 模块-&(点应用名展开)-&查看部署描述符，在 Servlet Mappings 中不曾发现有那个 /ReportServlet，原来是没有部署上 ReportServlet 啊。
此时，大家的心都飞到家里去了，本来打补丁就是选择晚上下班后 9 点以后没什么用户访问才进行的，正有些焦头烂额，甚至是考虑发布整个应用，但碍于正式环境上的应用是许久以前发布的，一直是不断打补丁补掇起来的。完全重新发布应用自然是有很大的风险性，本地代码即使是 VSS 代码与正式环境不同步那是常用事(唉，不想扯另一话题的)。差点订下规定说，以后能有别的技术方法实现的，就不要去改 web.xml 文件。
有些当然只是说说罢了，实际摆在面前的是硬着头皮也要上，明天业务不能中断的。
那若不是 WAS_HOME/installedApps/unmi/Prod_war.ear/Prod.war/WEB-INF/web.xml 在起作用，又会是哪个文件呢？于是搜索 WAS_HOME 目录下的所有 xml 文件，看哪个文件中有内容 ReportServlet，终于发现是藏匿在 WAS_HOME/config/cells/unmi/applications/Prod_war.ear/deployments/Prod_war/Prod.war/WEB-INF/ 中，对了，就是这里，把要更新的 web.xml 替换掉这个目录中的 web.xml，然后重启应用，OK，ReportServlet 可用了，一切正常。
细心点你会发现在 WAS_HOME/config/cells/unmi/applications/Prod_war.ear/deployments/Prod_war/Prod.war/WEB-INF/& 可以看到你的 war 包中的 WEB-INF 目录下的所有文件，连 struts-config.xml 等都在这里了。其实在这个目录中除 web.xml、ibm-web-bnd.xmi& 有关部署描述文件外，实际应用运行是不会使用此目录中的其他文件的，struts-config.xml 等在这里只不过一个摆设；同样不客气的是，在目录 WAS_HOME/installedApps/unmi/Prod_war.ear/Prod.war/WEB-INF 中作客的 web.xml 也只是充个样罢了，毫无用处，还混淆了视听。
前面主戏算是过去了，然余震未断。上面的故事是假设把应用部署在非集群的环境，实际情况是部署在集群环境的。集群环境中 Prod.war 部署后所在的目录就会是 WAS_HOME/installedApps/unmiNetwork/Prod_war.ear/Prod.war，所以，基于这一实际，需要做的就应把 web.xml 覆盖到 WAS_HOME/config/cells/unmiNetwork/applications/Prod_war.ear/deployments/Prod_war/Prod.war/WEB-INF 这个目录中去。
可是有一天，突然发现那个 /ReportServlet 又访问不到了，查看一下 WAS_HOME/config/cells/unmiNetwork/applications/Prod_war.ear/deployments/Prod_war/Prod.war/WEB-INF/web.xml 的内容，发现怎么又恢复成原样了呢？有关 ReportServlet 的配置不见了，顿时不知所以。隐约间还是回想了起来，原来整个应用及 DeploymentManager(DM) 都重启了，肯定是 DeploymentManager 作的怪。找了找，发现在 DM_HOME/config/cells/unmiNetwork/applications/Prod_war.ear/deployments/Prod_war/Prod.war/WEB-INF 中也有一个 web.xml (DM_HOME 代表 DeploymentManager 的安装目录)，就它还是老样，重启 DM 肯定又用这个同步到了各节点去的。于是乎把此处的 web.xml 也换成新的了，以后无论是重启应用服务器还是 DM 都不会有问题了。
本文侧重于发现问题及解决问题的过程，过程中才有乐趣，但对于务实且重效率的人固然是看了会眼花。因此最后还是总结一下吧：
WAS 下的 Web 应用，如果要更新 web.xml 文件，该替换哪一个 web.xml 呢？
·非集群环境要更新 WAS_HOME/config/cells/[unmi]/applications/[Prod_war.ear]/deployments/[Prod_war]/[Prod.war]/WEB-INF/ 中的 web.xml& 文件
·集群环境则，只是做了上一步，重启应用后确实有效果，但若要在 DM 重启后仍然有效的话，还需更新
&&& DM_HOME/config/cells/[unmiNetwork]/applications/[Prod_war.ear]/deployments/[Prod_war]/[Prod.war]/WEB-INF 中的 web.xml 文件
·如果只更新 WAS_HOME/installedApps/[unmi]/[Prod_war.ear]/[Prod.war]/WEB-INF/web.xml (非集群环境) 或
&&& WAS_HOME/installedApps/[unmiNetwork]/[Prod_war.ear]/[Prod.war]/WEB-INF/web.xml (集群环境) 都是无济于事的。
·WAS_HOME 和 DM_HOME 分别代表 AppServer 和 DeploymentManager 的安装目录。集群和非集群情况下有一个目录的差别就是有无 "Network"，指默认安装情况了。以上中括号中的内容视你的具体情况而定的，WAS 和 DM 是把部署描述文件和程序文件分离的，其实有时还是有它好处的。非集群环境没怎么感觉到，集群环境还是能感觉到，就是在节点间进行配置同步的时候。
wu_jiaxiang
浏览: 24902 次
来自: 北京
再次表示谢谢
谢谢·····
感谢，2004年编写的...
(window.slotbydup=window.slotbydup || []).push({
id: '4773203',
container: s,
size: '200,200',
display: 'inlay-fix'}