NO.93 WebLogic1213升级常见问题总结

不断更新中……

背景:公司内系统原部署在WebLogic9、10,现升级至WebLogic1213。

3.1 连接单点系统的系统必须添加SSL协议版本启动参数

1. 连接单点系统的系统必须添加SSL协议版本启动参数问题场景

单点系统于在WLS9,连接单点系统的升级验证系统部署于WLS12C。

2. 问题现象

升级验证系统端启动后,访问首页时后台报错:

java.io.IOException: Connection closed, EOF detected 
at weblogic.socket.JSSEFilterImpl.handleUnwrapResults(JSSEFilterImpl.java:619) 
atweblogic.socket.JSSEFilterImpl.unwrapAndHandleResults(JSSEFilterImpl.java:498) 
at weblogic.socket.JSSEFilterImpl.doHandshake(JSSEFilterImpl.java:93) 
at weblogic.socket.JSSEFilterImpl.doHandshake(JSSEFilterImpl.java:71) 
at weblogic.socket.JSSEFilterImpl.write(JSSEFilterImpl.java:434) 

Truncated.see log file for complete stacktrace

3. 问题原因

WLS12.1.1基于JDK7,WLS9基于JDK5,而JDK7默认的SSL协议版本与JDK5不一致。

4. 验证系统端解决方案

请在升级验证系统启动domain的JAVA_OPTIONS参数中加入下面的参数:

-Dweblogic.security.SSL.protocolVersion=SSL3

5. 单点系统端解决方案

将单点系统中间件升级至WLS12C(依赖单点登录系统WLS12升级上线)

注:按整体升级方案,前期会先升级周边系统,因此周边连接单点的系统须先采用验证系统端解决方案。

3.2 Arch4框架注意在pre-classpath中配置antlr-*.jar

1. 问题现象

系统启动后,后台报出以下错误:

ClassNotFoundException: org.hibernate.hql.ast.HqlToken.

2. 解决方案1

在启动命令中加入以下参数:

Cmd版:

@REM 在preclasspath中引入antlr包(建议将工程中的antlr-2.7.6.jar放在一个公共位置,如下)

set LIB_PATH=F:\00\projects\interface_test\WEB-INF\lib

set EXT_PRE_CLASSPATH=%LIB_PATH%\antlr-2.7.6.jar

Shell版:

export LIB_PATH=/home/apps/pdfbpoc/webapp/WEB-INF/lib

export EXT_PRE_CLASSPATH=${LIB_PATH}/antlr-2.7.6.jar

3. 解决方案2

在weblogic.xml添加以下黄底色部分内容。

    <!-- container-descriptor 元素指定影响 Web 应用程序行为的参数列表。 -->

    <container-descriptor>

        <!-- 定义WebLogic Server是否执行servlet检查以查看servlet是否已更改,如果已更改,是否重新加载。

            -1:永不检查(生产环境中的默认值),

            0:表示总是检查servlet

            1:每秒检查一次(开发环境默认值) -->

        <servlet-reload-check-secs>1</servlet-reload-check-secs>

 

        <!-- 针对 Web应用程序范围内资源路径中发现的缓存资源执行元数据缓存。该参数标识WebLogic Server检查资源是否发生修改的频率,如果已修改,则重新加载。

            -1: 表示元数据进行缓存,但从不对磁盘进行检查以便找出所做的更改。建议在生产环境中使用该值,以提升性能。

            0: 表示不执行元数据缓存。持续更改文件的客户必须将该参数设置为大于或等于 0的一个值。

            1: 表示每秒重新加载一次。该值为开发环境中的默认值。 -->

        <resource-reload-check-secs>1</resource-reload-check-secs>

       

        <prefer-web-inf-classes>false</prefer-web-inf-classes>

       

        <prefer-application-packages>

            <package-name>org.slf4j.*</package-name>

            <package-name>org.apache.commons.*</package-name>

            <package-name>antlr.*</package-name>

        </prefer-application-packages>

 

        <prefer-application-resources>

            <resource-name>org/slf4j/impl/StaticLoggerBinder.class</resource-name>

        </prefer-application-resources>

    </container-descriptor>

3.3 ILOG6.5需配套升级至8.5

原使用ILOG6.5的系统,ILOG需升级至8.5版本。

3.4 LogBack.xml不能正常读取

1. 问题现象

系统日志组件使用slf4j+LogBack,原在WebLogic9下部署可以生成日志,升级为WebLogic12C后无法生成日志,LogBack.xml看起来像是无法正常读取。

2. 问题成因

为项目中slf4japi与weblogic中冲突引起。

3. 解决方案

在webLogic.xml中添加以下红色字体部分内容:

<!-- container-descriptor 元素指定影响 Web应用程序行为的参数列表。-->

<container-descriptor>

    <!-- 定义 WebLogic Server是否执行 servlet检查以查看 servlet 是否已更改,如果已更改,是否重新加载。

       -1:永不检查(生产环境中的默认值),

       0:表示总是检查 servlet

       1:每秒检查一次(开发环境默认值) -->

    <servlet-reload-check-secs>-1</servlet-reload-check-secs>

 

    <!-- 针对 Web应用程序范围内资源路径中发现的缓存资源执行元数据缓存。该参数标识 WebLogic Server检查资源是否发生修改的频率,如果已修改,则重新加载。

       -1: 表示元数据进行缓存,但从不对磁盘进行检查以便找出所做的更改。建议在生产环境中使用该值,以提升性能。

       0: 表示不执行元数据缓存。持续更改文件的客户必须将该参数设置为大于或等于 0的一个值。

       1: 表示每秒重新加载一次。该值为开发环境中的默认值。-->

    <resource-reload-check-secs>-1</resource-reload-check-secs>

   

    <prefer-web-inf-classes>false</prefer-web-inf-classes>

    <show-archived-real-path-enabled>true</show-archived-real-path-enabled>

         <prefer-application-packages> 

           <package-name>org.slf4j</package-name> 

         </prefer-application-packages>

</container-descriptor>

3.5   xstream转换报文报错

1. 问题现象

系统报出xtream有关的错误,实际上是XML转换不完全致XML无法正常读取分析:

com.thoughtworks.xstream.converters.ConversionException:Timestamp format must be yyyy-mm-ddhh:mm:ss[.fffffffff] : Timestamp format mustbe yyyy-mm-dd hh:mm:ss[.fffffffff]

2. 问题成因

待分析。

3. 解决方案

修改XFireServlet-servlet.xml配置文件,删除<ref bean="DOMInHandler"/>节点以修复此问题;

3.6应用在win环境的WLS12C下无问题,但在Linux的WLS12C下部署时报NullPointerException

1. 问题现象

部署时即报以下错误:

####<Feb 3, 2015 11:13:31 AM CST> <Error><Deployer> <YFCSPT-SUSE-100> <AdminServer> <[ACTIVE]ExecuteThread: '0' for queue: 'weblogic.kernel.Default (self-tuning)'><<WLS Kernel>> <> <> <1422933211514><BEA-149205> <Failed to initialize the application "webapp"due to error java.lang.NullPointerException

java.lang.NullPointerException

atweblogic.application.utils.annotation.ClassfinderClassInfos.polulateOneClassInfo(ClassfinderClassInfos.java:143)

atweblogic.application.utils.annotation.ClassfinderClassInfos.populateClassInfos(ClassfinderClassInfos.java:137)

atweblogic.application.utils.annotation.ClassfinderClassInfos.<init>(ClassfinderClassInfos.java:28)

atweblogic.servlet.internal.War.initializeClassInfosIfNecessary(War.java:443)

atweblogic.servlet.internal.War.getAnnotatedClasses(War.java:373)

 

2. 问题成因

WLS1211在部署应用时对所有文件进行预加载及校验,如文件名中有乱码将导致校验失败。

3. 解决方案

操作系统配置系统默认语言为zh_CN.GBK。

vi /etc/profile

在文件尾部添加:

export LC_ALL=zh_CN.GBK

3.7 JS文件中alert、congfirm或innerHTML等需要显示在页面的中文乱码

1. 问题现象

同标题,一般见于字符集为UTF-8的系统。

2. 问题原因

WLS12.1.3上增强了对JavaScript的mime type处理,增加了响应头中ContentType的设置,代码片段如下:

public staticfinal String[][] DEFAULT_MIME_MAPPINGS = {

...

   { "js","text/javascript" },

}

JS乱码是由于浏览器加载JS文件的响应头Content-Type中charset=GBK或GB2312编码导致的,而GBK或GB2312编码是由web.xml文件中定义的struts过滤器加入的,配置片段如下:

<filter>

 <filter-name>struts2</filter-name>   <filter-class>org.apache.struts2.dispatcher.ng.filter.StrutsPrepareAndExecuteFilter</filter-class>

</filter>

<filter-mapping>

 <filter-name>struts2</filter-name>

  <url-pattern>/*</url-pattern>

</filter-mapping>

3. 解决方案1

如工作量不大,可考虑将JS文件中需要显示的汉字替换为unicode,如:

alert(‘汉字’);

代替

alert(‘\u6c49\u5b57’);//汉字

这是一个unicode转换站点:

http://tool.chinaz.com/Tools/Unicode.aspx

4. 解决方案2

web.xml中增加js的mime-mapping配置,指定需要的编码类型,extension为js,mime-type为text/javascript;charset=UTF-8。比如:

<mime-mapping>

        <extension>js</extension>

        <mime-type>text/javascript;charset=UTF-8</mime-type>

</mime-mapping>

注意:使用该方案后,如果工程中有用非UTF-8(如GBK)编码的JS文件,需重新按UTF-8再次编辑。


猜你喜欢

转载自blog.csdn.net/amosryan/article/details/43410071
93