simonhc 2011-09-14
转载自lontoo
Spingframework-2.5.5
Struts-2.0.11
Sitemesh-2.4.1
Hibernate-3.2.6(antlr-2.7.7.jar)
WeblogicServer10.3.1(多语言版本—中文版)【javaversion"1.6.0_11"】
1、包antlr冲突问题
org.hibernate.QueryException:
ClassNotFoundException:org.hibernate.hql.ast.HqlToken
引起这个问题的原因是包antlr2.6.1.jar在WEBLOGIC10.3中与项目中HIBERNATE3.x用来解析SQL语句的包antlr-2.7.7.jar冲突了。
大致有3种方式可以解决这类问题:
1)在启动weblogic时,优先启动项目中使用到的antlr-2.7.7.jar的文件。在weblogic启动文件的classpath上优先增加antlr-2.7.7.jar文件。如下:
setSAVE_CLASSPATH=.;d:\antlr-2.7.7.jar;%CLASSPATH%
注意:
你必须把antlr-2.7.7.jar拷贝到d:目录下或者其他你自己设定的目录名。
2)在hibernate.properties或者hibernate-cfg.xml,或者db-jdbc.properties中设置一个属性hibernate.query.factory_class的值为
org.hibernate.hql.classic.ClassicQueryTranslatorFactory
注意:
●选择Hibernate3.x的查询翻译器:
org.hibernate.hql.ast.ASTQueryTranslatorFactory
●选择Hibernate2.x的查询翻译器
org.hibernate.hql.classic.ClassicQueryTranslatorFactory
3)在/WEB-INF目录下增加或者修改weblogic.xml文件。
<container-descriptor>
<prefer-web-inf-classes>true</prefer-web-inf-classes>
</container-descriptor>
注意:
●这个方法不是推荐的,因为这个设置可能会引起JSTL的设置冲突。
2、Servlet2.5规范问题
如果使用servlet2.5规范来配置web.xml文件。在系统启动时出现以下错误:
java.lang.IllegalArgumentException:Illeagalcombination-Mode.PAYLOADandProvider<javax.xml.soap.SOAPMessage>
atcom.sun.xml.ws.server.provider.ProviderEndpointModel.<init>(ProviderEndpointModel.java:111)
atcom.sun.xml.ws.server.provider.ProviderInvokerTube.create(ProviderInvokerTube.java:63)
解决的方法
1)使用web.xml2.4的规范而不是使用web.xml2.5规范;
2)在weblogic.xml中设置(参见上面的说明):
<prefer-web-inf-classes>true</prefer-web-inf-classes>;
3、装饰器无法正常工作
装饰器无法正常工作,只能返回请求页面,不会对页面进行任何装饰。比如提交一个struts2请求/portal/abc.do,同时也设置了sitemesh过滤器映射这个请求,以及在decorators.xml中也设置了装饰器,比如:
<decoratorname="foreDecorator"page="template.jsp">
<pattern>/portal/abc.do</pattern>
</decorator>
现在假设struts2请求/portal/abc.do将会返回到一个页面abc.jsp页面。结果,页面只返回了abc.jsp页面上的数据,而没有被template.jsp页面进行装饰。通过查看源代码发现。在准备装饰之时,weblogic的request.getServletPath()得到是abc.jsp,而不是/portal/abc.do。
因此在decorators.xml并不能找到需要装饰的mapping。除非将<pattern>/portal/abc.do</pattern>修改为:
<pattern>/abc.jsp</pattern>
是可以被映射并装饰了。
解决的方法
修改sitemesh的对应的decoratormapping源代码。在这里这个文件是:
com\opensymphony\module\sitemesh\mapper\ConfigDecoratorMapper.java
修改这个文件。使用request.getRequestURI()代替request.getServletPath()来获得待匹配的URL。
4、Sitemesh乱码问题
关于sitemesh乱码问题,除了与Tomcat环境下的设置以外。比如:
通过过滤器设置:
request.setCharacterEncoding(encoding);
response.setCharacterEncoding(encoding);
JSP文件设置:
<%@pagecontentType="text/html;charset=UTF-8"pageEncoding="UTF-8"%>
Weblogic针对sitemesh方面还有3个地方出现乱码:
1)在装饰器文件中使用<decorator:body/>乱码。这个是最常用的,也就是最常见的乱码问题。
2)page:applyDecorator,指定了待装饰的jsp文件,比如:t1.jsp:
<page:applyDecoratorpage="t1.jsp"name="t1Decorator"/>
这样t1.jsp渲染后出现乱码。
3)一个请求通过了sitemesh过滤器,但同时又没有找到对应的装饰器(同时并不在excludes中指定),这样就是使用默认的装饰器(NoDecorator)进行直接输出。
com.opensymphony.sitemesh.webapp.decorator.NoDecorator
虽然是各种不同的情况,但原因都有些类似,就是在weblogic环境下,Sitemesh在装饰页面时,如果response的contentType为null,则使用java虚拟机属性值"file.encoding",而该值与操作系统相关,在windows系统下,该值=GBK.由于页面本身是UTF-8编码的,经过sitemesh装饰后,使用GBK编码转换,产生乱码。
解决的方法
既然跟file.encoding有关系,那么就直接设置这个系统属性可以解决上面的全部问题。解决如下:在weblogic启动文件的启动参数上增加-Dfile.encoding。如下:
setSAVE_JAVA_OPTIONS=%JAVA_OPTIONS%-Dfile.encoding=UTF-8
注意:
●这个方法简单明了,而且不用修改其他方面;
●但是,如果这样设置的话,Weblogic本身的启动等相关信息就乱码了。
因此,在下面使用其他的方式来解决上面的3个问题:
1)通过查看源代码,发现进行内容装饰之前需要进行对内容字节转换成字符串,在转换的时候,如果没有获得编码,那么就是用file.encoding。因此,可以修改这个文件,使默认使用的编码为”UTF-8”.
com.opensymphony.module.sitemesh.filter.TextEncoder
2)page:applyDecorator,指定了待装饰的jsp文件,那么,同时需要指定这个文件使用的编码。如下:
<page:applyDecoratorpage="t1.jsp"name="t1Decorator"encoding="UTF-8"/>
3)针对第3个乱码问题,可以通过修改如下文件:
com.opensymphony.sitemesh.webapp.decorator.NoDecorator
让输出的字符串作为UTF-8的方式直接输出到response中。
5、<c:import…>乱码问题
所包含的文件需要使用charEncoding="UTF-8"进行限定。
<c:importurl="/portal/block/userBlock11.jsp"charEncoding="UTF-8"/>