当前位置: 首页 > 知识库问答 >
问题:

WebLogic 12c中的Guava 15.0 jar冲突

董哲
2023-03-14

我在部署在WebLogic 12c上的应用程序中从guava 14.0.1更新到15.0,在部署期间我得到了一个java.lang.NoSuchmetodException,我一直无法解决:

Caused By: java.lang.NoSuchMethodException: com.google.common.base.internal.Finalizer.startFinalizer(java.lang.Class, java.lang.ref.ReferenceQueue, java.lang.ref.PhantomReference)
    at java.lang.Class.getMethod(Class.java:1624)
    at com.google.common.base.FinalizableReferenceQueue.getStartFinalizer(FinalizableReferenceQueue.java:302)
    at com.google.common.base.FinalizableReferenceQueue.<clinit>(FinalizableReferenceQueue.java:90)
    at java.lang.Class.forName0(Native Method)
    at java.lang.Class.forName(Class.java:266)
    at com.oracle.injection.provider.weld.BasicResourceLoader.classForName(BasicResourceLoader.java:27)
    at org.jboss.weld.bootstrap.BeanDeployer.loadClass(BeanDeployer.java:107)
    at org.jboss.weld.bootstrap.BeanDeployer.addClass(BeanDeployer.java:77)
    at org.jboss.weld.bootstrap.BeanDeployer.addClasses(BeanDeployer.java:135)
    at org.jboss.weld.bootstrap.BeanDeployment.createBeans(BeanDeployment.java:184)
    at org.jboss.weld.bootstrap.WeldBootstrap.deployBeans(WeldBootstrap.java:349)
    at com.oracle.injection.provider.weld.WeldInjectionContainer.deploy(WeldInjectionContainer.java:99)
    at com.oracle.injection.integration.CDIAppDeploymentExtension.initCdi(CDIAppDeploymentExtension.java:68)
    at com.oracle.injection.integration.CDIAppDeploymentExtension.activate(CDIAppDeploymentExtension.java:47)
    at weblogic.application.internal.flow.AppDeploymentExtensionFlow.activate(AppDeploymentExtensionFlow.java:37)
    at weblogic.application.internal.BaseDeployment$2.next(BaseDeployment.java:729)
    at weblogic.application.utils.StateMachineDriver.nextState(StateMachineDriver.java:42)
    at weblogic.application.internal.BaseDeployment.activate(BaseDeployment.java:258)
    at weblogic.application.internal.EarDeployment.activate(EarDeployment.java:61)
    at weblogic.application.internal.DeploymentStateChecker.activate(DeploymentStateChecker.java:165)
    at weblogic.deploy.internal.targetserver.AppContainerInvoker.activate(AppContainerInvoker.java:80)
    at weblogic.deploy.internal.targetserver.operations.AbstractOperation.activate(AbstractOperation.java:586)
    at weblogic.deploy.internal.targetserver.operations.ActivateOperation.activateDeployment(ActivateOperation.java:148)
    at weblogic.deploy.internal.targetserver.operations.ActivateOperation.doCommit(ActivateOperation.java:114)
    at weblogic.deploy.internal.targetserver.operations.AbstractOperation.commit(AbstractOperation.java:339)
    at weblogic.deploy.internal.targetserver.DeploymentManager.handleDeploymentCommit(DeploymentManager.java:846)
    at weblogic.deploy.internal.targetserver.DeploymentManager.activateDeploymentList(DeploymentManager.java:1275)
    at weblogic.deploy.internal.targetserver.DeploymentManager.handleCommit(DeploymentManager.java:442)
    at weblogic.deploy.internal.targetserver.DeploymentServiceDispatcher.commit(DeploymentServiceDispatcher.java:176)
    at weblogic.deploy.service.internal.targetserver.DeploymentReceiverCallbackDeliverer.doCommitCallback(DeploymentReceiverCallbackDeliverer.java:195)
    at weblogic.deploy.service.internal.targetserver.DeploymentReceiverCallbackDeliverer.access$100(DeploymentReceiverCallbackDeliverer.java:13)
    at weblogic.deploy.service.internal.targetserver.DeploymentReceiverCallbackDeliverer$2.run(DeploymentReceiverCallbackDeliverer.java:68)
    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)

我已经在我的WebLogic中使用了WebLogic prefer应用程序包classloader过滤。xml文件,以解决WebLogic 12c中的运行时冲突,因为它似乎要重新打包库的旧版本。这在guava 14.0.1中一直有效,但在15.0中没有。

据我所知,我更喜欢com.google.普通。*包装应包括所有内容。这个终结器类是否在类加载器过滤之前做了一些特殊的事情,从而尝试加载似乎具有不同API的旧版本?

使用番石榴-15.0有替代方案吗。jar与应用程序打包,而不是与服务器捆绑?

共有2个答案

邓昀
2023-03-14

作为一个传统的信息,我在升级到Weblogic 12c时遇到了一个类似的问题,因为WL和Guava之间存在冲突(已经尝试了Guava的11和18版本)。

我发现解决方案是明确地选择应用程序的lib。我在我的weblogic上设置了这个。xml:

<prefer-application-packages>
  <package-name>com.google.common</package-name>
</prefer-application-packages>

参考http://docs.oracle.com/middleware/1212/wls/WLPRG/classloading.htm#WLPRG315。

秦皓君
2023-03-14

修复此问题后,出现了一个针对此问题的开放问题#1527(Guava 15无法部署到任何JEE6容器)。请加星号和/或注释,等待修复(注释#33表明版本15.0.1可能在不久的将来发布)。

编辑:同时,新maven版本解决了这个问题:

在Guava 15.0中添加了一个解决方法,使其与CDI 1.1(用于JEE7容器)兼容,这给带有CDI 1.0(用于JEE6容器)的Guava带来了问题。

如果你在CDI 1.0环境中使用番石榴,你应该使用番石榴-15.0-cdi1.0。而不是普通的番石榴罐。在Maven中,依赖项可以指定为:

<dependency>
  <groupId>com.google.guava</groupId>
  <artifactId>guava</artifactId>
  <version>15.0</version>
  <classifier>cdi1.0</classifier>
</dependency>

如果要在JEE 6和7服务器上部署,则必须使用Guava 13或等到16发布。

 类似资料:
  • 我正在使用下面的命令检查12C中Weblogic服务器的状态,该命令在10.x Weblogic中正常工作 java weblogic.admin-URL t3:/$IP:$端口getstate-username$username-password$password 我将类路径设置如下导出classpath=$WL_HOME/server/lib/weblogic.jar

  • 我在eclipse中使用“Jersey”原型开发了一个非常小的restful Web服务,并且在Tomcat中成功地部署了该服务。但是,我无法在WebLogic12c中部署它。这是我到目前为止所尝试的: 创建了一个包含泽西岛图书馆的共享库,正如我在其中一篇文章中看到的。这是我的pom.xml,它生成包含所需清单文件的共享库: 块引号 在我的webservice应用程序中的WEB-INF文件夹下添加

  • 我有这个问题,一个应用程序耳朵有这个错误,我是一个weblogic12c的新管理员,有人帮助我吗??? 这是一个标准安装Weblogic 12c

  • 我得到的是“违反协议”。我有一个在RedHat Linux上运行的应用程序,数据库和应用程序共同驻留在机器上。 使用的Oracle版本:Oracle 11g R2(11.2.0.3.0) 使用的JDBC驱动程序:12.1.0.1 使用的Java:JDK1.7.0.65 32位 我遇到过很多论坛,这些论坛都指出这个错误是驱动程序的问题,但在所有这些论坛中,使用的oracle版本较高,而驱动程序版本较

  • 问题内容: Java 使用方法在中插入K / V对。可以说我使用过method,现在有一个条目,其值为10和17。 如果我在其中插入10,20,由于键10相同而发生冲突,它会简单地用该条目替换之前的条目。 如果钥匙碰撞,则用新的K / V对替换旧的K / V对。 所以我的问题是何时使用Chaining冲突解决技术? 为什么它没有形成键值为10且值为17,20的a? 问题答案: 当您插入线对然后时,

  • Java使用方法在中插入K/V对。假设我使用了方法,现在

  • 在运行react应用程序时,我在控制台中遇到了这个错误--从2021年5月左右的M91开始,SharedArrayBuffer将需要跨源隔离。请参阅https://developer.chrome.com/blog/enabling-shared-array-buffer/了解更多详细信息。 根据StackOverflow的建议,我尝试更新react版本。我的版本是16,然后转到了17。但现在依赖

  • 我们刚刚从DataStax Enteprise 3.2.2升级到4.5.1。我们从3.2.2->3.2.5->4.0.3->4.5.1迁移,每次都遵循文档中的过程,并在每次升级后升级sstables。 服务器正在运行,核心正常接受查询。 当将数据映射类型从“2”更改为“1”,并通过API发布配置和模式时,我会得到以下结果: solrexception:org.apache.Solr.common.