Конфликт jar Guava 15.0 в WebLogic 12c

Я обновился с guava 14.0.1 до 15.0 в приложении, которое развертывается на WebLogic 12c, и во время развертывания я получаю исключение java.lang.NoSuchMethodException, которое мне не удалось разрешить:

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 Preference-Application-Packages в моем файле weblogic.xml, как описано здесь, чтобы разрешить конфликт во время выполнения в WebLogic 12c, поскольку он, похоже, переупаковывает более старую версию библиотеки. Это работало в гуаве 14.0.1, но не в 15.0.

Насколько я могу судить, пакет com.google.common.* должен включать все. Делает ли этот класс Finalizer что-то особенное, что происходит до того, как происходит фильтрация загрузчика классов, тем самым пытаясь загрузить старую версию, которая, по-видимому, имеет другой API?

Есть ли альтернативное решение для использования guava-15.0.jar, упакованного с приложением, вместо того, что идет в комплекте с сервером?


guava weblogic12c
person eggilbert    schedule 27.10.2013    source источник

Ответы (2)


arrow_upward
9
arrow_downward

Существует открытая проблема № 1527, посвященная этой проблеме (Guava 15 нельзя развернуть на любой контейнер JEE6), который возник после исправления этого. Пометьте и/или прокомментируйте и дождитесь исправления (комментарий № 33 предполагает, что версия 15.0.1 может быть выпущена в ближайшем будущем).

EDIT: тем временем проблема была решена от новой версии maven:

Примечание по JEE6/CDI 1.0

Обходной путь, добавленный в Guava 15.0, чтобы сделать его совместимым с CDI 1.1 (используется в контейнерах JEE7), вызывал проблемы для Guava с CDI 1.0 (используется в контейнерах JEE6).

Если вы используете Guava в среде CDI 1.0, вам следует использовать guava-15.0-cdi1.0.jar вместо обычного jar-файла Guava. В 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.

person Xaerxess    schedule 28.10.2013
comment
Спасибо за информацию. Я прочитал темы и попытался удалить beans.xml из guava-15.0.jar, поскольку WebLogic 12c является сервером JEE6, и это, похоже, решило проблему. Думаю, сейчас лучше всего просто вернуться к 14.0.1, пока не появится новая версия 15, которая работает без изменений. - person eggilbert; 28.10.2013

arrow_upward
2
arrow_downward

В качестве дополнительной информации я столкнулся с этим вопросом с аналогичной проблемой при обновлении до Weblogic 12c из-за конфликта между WL и Guava (пробовал с версиями 11 и 18 Guava).

Я обнаружил, что решение заключается в том, чтобы явно предпочесть библиотеку моего приложения. Я установил это в своем 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 для справки.

person Ric    schedule 27.02.2015
comment
Имя пакета должно быть ‹package-name›com.google.common‹/package-name›. - person Zeta; 24.03.2016
comment
Спасибо, Зета, за указание на это. Не знаю, где я взял организационную часть. Просто отредактировано в соответствии с вашим предложением. - person Ric; 04.06.2016