java.lang.LinkageError: LinkageError while defining class

■·在这个社会上最让人欣慰的是,几乎没有人会真正跌入低谷 ■·最可悲的是明明有能力飞,但很少有人飞到高处

 

问题分类:程序发布

影响部门:音像资料馆3694

 

软件名称：websphere
软件版本：v5.1
环境平台：linux

问题描述：

1.本地tomcat+myeclipse+jdk1.4开发程序文件class发至测试环境(linux+was5.1) 结果:测试通过
2.将通过文件发至正式环境(linux+was5.1) 结果：失败

 

注:前后两个环境发布过程中均为直接替换文件的方式!

 

Error log:

 

Caused by: java.lang.LinkageError: LinkageError while defining class: com.ctvit.medialog.dy.impl.MedialogTypeImpl$MediaTypesTypeImpl

Could not be defined due to: com/ctvit/medialog/dy/impl/MedialogTypeImpl$MediaTypesTypeImpl (Bad magic number)

This is often caused by having a class defined at multiple

locations within the classloader hierarchy. Other potential causes

include compiling against an older or newer version of the class

that has an incompatible method signature.

Dumping the current context classloader hierarchy:

==> indicates defining classloader

==>[0] 

com.ibm.ws.classloader.CompoundClassLoader@2d2e87c2

 

分析:

 

原因可能如下:

l          一种是编译自定义类的jdk与服务器的jdk不一致,也就是说两个操作系统下的服务器中的jdk版本不一致.（己排除）

l          另一种是由于自定义的类在服务器中存在重复定义.(有可能)

l          上传的文件已经损坏。本机器通过SSH上传过程中文件已经损坏。属于本机问题。(此情况几率较小)

l          最大的疑点classLoader冲突(有可能)

l          用低版本的文件替换至新版本文件时就会出现此错误

 

 Bad magic number:

        Java编译后的class二进制文件（以class结尾）可以通过网络传输。有时候在传输文件的过程中，连接可能会被中断或受干扰，使得class 文件装载失败；有时候当拷贝文 件到web服务器时，文件会被混淆或者发生磁盘错误。因此，JVM和class loader提供了特别的手段去验证类文件是否完整。一个预防就是每个类定义的开始包含了magic number， 这是一串四位的字节数组用来标记该文件之所以为类定义文件。 对于那些很想知道magic number是什么的人来说，它就是一个16进制数CAFEBABE，class loader用它来确定一个文件是否真得是类文件。

 

 操作过程:

 

1.      第一步将正式环境上medialog.war整个应用down至测试环境,结果测试通过;

2.      第二步将本地修改文件替换至测试环境,结果测试通过;

3.      第三步将测试环境中替换的文件发布至正式环境;

4.      第四步发布之后重启medialog.war应用并进行测试;

5.      第五步如果测试不通过，重启WebShpere，再进行测试;

6.      第六步测试再不通过,将正式环境中己替换文件并出错的medialog.war下载至测试环境,再在测试环境中进行测试是否通过;

7.      最终结果如果失败即刻回退正式环境的操作.

 

替换程序时需注意:

l          在替换文件之前务必将正式环境的medialog服务关闭.

l          在关闭medialog服务之后上传替换文件,并保证上传替换的准确性.

l          替换文件之后,重新启动medialog服务,验证是否发布成功

 

 

注:之所以没有将本地开发的应用打包medialog.war发,因考虑到此应用程序近二年时间没有修改过,程序经手人也比较多,版本上控制的不是很好,所以不敢轻易的将本地程序直接打包分发.风险太大!

 

2010-11-24操作如下:

 

1.将本地程序打包medialog.war分发至测试环境,结果测试未通过.

       错误码：500
提示： Filter [myFilter]: could not be initialized

 

2.将通过的测试环境medialog.war导出ear.再进行测试环境分发,成功!但出现新的问题,导出的ear并非最新更新程序.

 

   原因:注意一下$was_home\config\cells\***Node01Cell\applications，这个目录下的文件

          由于更新应用程序的方法是直接替换，所以上面那个目录下的一些文件并没有同步更新，那么在控制台导出的文件版本必然要老很多

 

注:发布过程中需要注意以下几点

       1).应用程序的上下文设定为 “/medialog”.
       2).发布过程的资源绑定设定.jndi
       3).安装完成后，设置应用的“web模块的类载入方式”为 “PARENT_LAST”.

 
 

2010-11-25

 

计划将测试环境ear包导出成功并重新分发测试环境...

 

继续操作...待续...

 

2010-11-30

 

以上所有方案均未通过,不得已将整包发布,因此程序很久未曾修改,版本上可能与正式环境不一致,所以整包发布的风险较大,在测试环境中一定要将所有功能测通！

最终通过方案:

 

1.      将本地medialog.war打包发至测试环境并进行测试通过.

2.      将此medialog.war发至正式环境通过.