Java 我如何检查哪个类/jar导致了；无法从最终类“继承”；在战争部署期间？

我正在将WAR文件部署到Windows 7上的Weblogic 12.1.2服务器（也尝试了Mac OS X）

我得到一个例外（见下文）。看起来其中一个类引用的是某个父类的旧/新版本，它来自某个重复的jar

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

<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)

---

使用调试器，并在抛出
java.lang.VerifyError
时设置断点。在堆栈跟踪中与类加载器相关的部分中，至少有些方法应该具有参数，允许您确定它正在尝试（或失败）加载哪个类

虽然Weblogic是专有的，但Java本身是开源的，因此您可能会尝试从Java的
开始关注堆栈跟踪中的行。
但理论上，Java调试器甚至应该能够在某种程度上调试封闭的源代码。
我也有同样的问题。加载com.google.common.base.CaseFormat时发生此错误

解决办法是

1） 将com.google.common.*添加到weblogic-application.xml中的首选应用程序包块中

2） 还需要检查番石榴的版本。18岁之前的番石榴与JEE 6环境不兼容。在我的例子中，我将guava从15.0更新到18.0版本。
Wow，堆栈跟踪似乎没有提供任何帮助。这是一个很好的教训，告诉你为什么不回去把你发布的课程做成期末考试。祝你好运我猜在理论上，您可以编写一些东西来加载每个jar中的每个类，直到遇到这个问题为止。您必须完全按照WebLogic设置类路径（或者您的构建可能会发现这一点）。可能您可以尝试使用main（）方法编写一个独立的自定义类装入器类，这样它将尝试从目录逐个装入所有JAR中的所有类。由于这是一个独立的程序，您可以从命令行运行它，并找出哪个类违反了规则。这里是一个自定义类加载器的示例—我在Weblogic 12.1.2.0.0中使用反射依赖项和部署时遇到了完全相同的问题。将它从0.9.10升级到0.9.11（这也将Guava版本升级到了20.0）完成了这项工作。