【问题标题】:how can I check which class/jar is causing "Cannot inherit from final class" during WAR deployment?如何在 WAR 部署期间检查哪个类/jar 导致“无法从最终类继承”?
【发布时间】:2014-01-11 02:34:48
【问题描述】:

我正在将 WAR 文件部署到 Windows 7 上的 Weblogic 12.1.2 服务器(也尝试过 Mac OS X)。

我遇到了一个异常(见下文)。看起来其中一个类是指某个父类的旧/新版本,它来自一些重复的 jar。

我怎样才能找到导致它的类或 jar 文件?我的 WAR 文件在 WEB-INF/lib 中有一堆罐子...

<Error> <Console> <BEA-240003> <Administration Console encountered the following error: weblogic.application.ModuleException:
java.lang.VerifyError: Cannot inherit from final class
    at weblogic.application.internal.ExtensibleModuleWrapper.prepare(ExtensibleModuleWrapper.java:114)
    at weblogic.application.internal.flow.ModuleListenerInvoker.prepare(ModuleListenerInvoker.java:100)
    at weblogic.application.internal.flow.ModuleStateDriver$1.next(ModuleStateDriver.java:172)
    at weblogic.application.internal.flow.ModuleStateDriver$1.next(ModuleStateDriver.java:167)
    at weblogic.application.utils.StateMachineDriver$ParallelChange.run(StateMachineDriver.java:80)
    at weblogic.work.ContextWrap.run(ContextWrap.java:40)
    at weblogic.work.SelfTuningWorkManagerImpl$WorkAdapterImpl.run(SelfTuningWorkManagerImpl.java:550)
    at weblogic.work.ExecuteThread.execute(ExecuteThread.java:295)
    at weblogic.work.ExecuteThread.run(ExecuteThread.java:254)
Caused by: java.lang.VerifyError: Cannot inherit from final class
    at java.lang.ClassLoader.defineClass1(Native Method)
    at java.lang.ClassLoader.defineClass(ClassLoader.java:800)
    at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
    at weblogic.utils.classloaders.GenericClassLoader.defineClass(GenericClassLoader.java:385)
    at weblogic.utils.classloaders.GenericClassLoader.findLocalClass(GenericClassLoader.java:344)
    at weblogic.utils.classloaders.GenericClassLoader.findClass(GenericClassLoader.java:302)
    at weblogic.utils.classloaders.ChangeAwareClassLoader.findClass(ChangeAwareClassLoader.java:64)
    at java.lang.ClassLoader.loadClass(ClassLoader.java:425)
    at java.lang.ClassLoader.loadClass(ClassLoader.java:358)
    at weblogic.utils.classloaders.GenericClassLoader.loadClass(GenericClassLoader.java:180)
    at weblogic.utils.classloaders.ChangeAwareClassLoader.loadClass(ChangeAwareClassLoader.java:43)
    at com.oracle.injection.integration.BeanLoaderUtils.loadBeanClassesFromJar(BeanLoaderUtils.java:54)
    at com.oracle.injection.integration.BeanLoaderUtils.loadBeanClassesFromEmbeddedJar(BeanLoaderUtils.java:34)
    at com.oracle.injection.integration.CDIModuleExtension.loadBeanClassesFromEmbeddedJar(CDIModuleExtension.java:727)
    at com.oracle.injection.integration.CDIModuleExtension.makeInjectionArchivesForResourceType(CDIModuleExtension.java:526)
    at com.oracle.injection.integration.CDIModuleExtension.createLibInjectionArchives(CDIModuleExtension.java:486)
    at com.oracle.injection.integration.CDIModuleExtension.createWebModuleInjectionArchive(CDIModuleExtension.java:193)
    at com.oracle.injection.integration.CDIModuleExtension.createInjectionArchive(CDIModuleExtension.java:179)
    at com.oracle.injection.integration.CDIModuleExtension.postPrepare(CDIModuleExtension.java:85)
    at weblogic.application.internal.ExtensibleModuleWrapper$PrepareStateChange.next(ExtensibleModuleWrapper.java:297)
    at weblogic.application.internal.ExtensibleModuleWrapper$PrepareStateChange.next(ExtensibleModuleWrapper.java:285)
    at weblogic.application.utils.StateMachineDriver.nextState(StateMachineDriver.java:42)
    at weblogic.application.internal.ExtensibleModuleWrapper.prepare(ExtensibleModuleWrapper.java:109)

【问题讨论】:

  • 哇,堆栈跟踪似乎没有提供任何帮助。这是一个很好的教训,为什么不回去把你发布的课程定为最终课程。祝你好运!我想在理论上,你可以写一些东西来加载每个 jar 中的每个类,直到你遇到这个问题。您必须完全按照 WebLogic 的方式设置类路径(或者您的构建可能会捕捉到这一点)。
  • 也许您可以尝试使用 main() 方法编写一个独立的自定义类加载器类,这样它将尝试从一个目录中一个一个地加载所有 jar 中的所有类。由于这是一个独立程序,您可以从命令行运行它并找出哪个类违反了规则。这是自定义类加载器的示例 - codeslices.net/snippets/…

标签: java deployment jar weblogic war


【解决方案1】:

使用调试器,并在java.lang.VerifyError 的抛出处设置断点。在堆栈跟踪中与 ClassLoader 相关的部分中,至少一些方法应该有参数,以便您确定它正在尝试(和失败)加载哪个类。

虽然 Weblogic 是专有的,但 Java 本身是开源的,因此您可以尝试关注堆栈跟踪中以 at java. 开头的行但理论上 Java 调试器甚至应该能够在某种程度上调试封闭源代码.

【讨论】:

    【解决方案2】:

    我也有同样的问题。加载 com.google.common.base.CaseFormat 时出现此错误。

    解决办法是

    1) 将 com.google.common.* 添加到 weblogic-application.xml 中的 prefer-application-packages 块中。

    2) 还需要检查番石榴版本。 Pre 18 Guava 与 JEE 6 环境不兼容。就我而言,我将番石榴从 15.0 更新到 18.0 版本。

    【讨论】:

    • 我在使用反射依赖并在 Weblogic 12.1.2.0.0 中部署时遇到了同样的问题。将其从 0.9.10 升级到 0.9.11(这也将 Guava 版本升级到 20.0)完成了这项工作。
    猜你喜欢
    • 1970-01-01
    • 2011-12-07
    • 1970-01-01
    • 1970-01-01
    • 2018-04-10
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多