При миграции приложения с Glassfi sh 3.1.2.2 на Glassfi sh 4.1 на Glassfi sh 5.1 я столкнулся с неоднозначной проблемой зависимости. Журнал ошибок выглядел следующим образом:
[Payara 4.1] [SEVERE] [] [javax.enterprise.system.core] [tid: _ThreadID=141 _ThreadName=admin-thread-pool::admin-listener(8)] [timeMillis: 1588867965816] [levelValue: 1000] [[
Exception while loading the app : CDI deployment failure:WELD-001409: Ambiguous dependencies for type Validator with qualifiers @Default
at injection point [UnbackedAnnotatedField] @Inject private org.apache.bval.cdi.BValInterceptor.validator
at org.apache.bval.cdi.BValInterceptor.validator(BValInterceptor.java:0)
Possible dependencies:
- org.apache.bval.cdi.ValidatorBean@526d08fd,
- ValidatorBean [id=org.hibernate.validator.internal.cdi.ValidatorBean_default]
org.jboss.weld.exceptions.DeploymentException: WELD-001409: Ambiguous dependencies for type Validator with qualifiers @Default
at injection point [UnbackedAnnotatedField] @Inject private org.apache.bval.cdi.BValInterceptor.validator
at org.apache.bval.cdi.BValInterceptor.validator(BValInterceptor.java:0)
Possible dependencies:
- org.apache.bval.cdi.ValidatorBean@526d08fd,
- ValidatorBean [id=org.hibernate.validator.internal.cdi.ValidatorBean_default]
Я провел параллельные тесты на Payara 4.1 и Payara 5.1, потому что некоторые вводящие в заблуждение намеки предполагали, что проблема связана с серверной платформой.
Однако проблема в моем случае заключалась в том, что была указана ссылка на openjpa-all-2.4.3.jar. Этот jar включает в себя все пакеты, необходимые для использования всех функций OpenJPA, к сожалению, также org.apache.bval.cdi.ValidatorBean. Для справки, для Glassfi sh 4.1 и Glassfi sh 5 я уже обновился до openjpa-all-3.1.0.jar. Хотя включение openjpa-all-*.jar не казалось проблемой в среде Glassfi sh 3 (java ee 6), поскольку пакеты, предоставляемые сервером java ee, отличались от пакетов, включенных в приложение, это стало проблемой на Glassfish / Payara 4. *, а также на Glassfish / Payara 5. *, потому что эти серверы уже предоставляют некоторые пакеты.
Таким образом, наиболее важными частями этих записей журнала являются org.apache.bval.cdi.ValidatorBean и ValidatorBean [id=org.hibernate.validator.internal.cdi.ValidatorBean_default]. Один из этих пакетов / пространств имен загружается дважды. В моем случае org.apache.bval.cdi.ValidatorBean уже был предоставлен jar на сервере java ee, соответственно bean-validator-cdi.jar на Glassfi sh 4. и 5. .
Итак, решение здесь , чтобы просто включить openjpa-3.1.0.jar и необходимые ссылки для проекта (вы найдете их в zip-файле openjpa в библиотеках. В моем случае и для этого проекта это были serp-1.15.1.jar, xbean-asm7-shaded-4.12.jar и commons-collections4-4.3.jar.
Я думаю, вся эта проблема возникает в основном, когда собственная библиотека JPA (hybernate, openjpa, et c.) используется вместо библиотеки по умолчанию на сервере java ee Аналогично, когда зависимость уже включает несколько других пакетов, которые также могут быть предоставлены существующей зависимостью или библиотекой, предоставленной сервером.
Я также пробовал подход asadmin set configs.config.server-config.cdi-service.enable-implicit-cdi=false, описанный здесь , а также идею приоритета определенных загрузчиков классов над другими, как описано в документации glassfish / payara , но те просто перенеси вопрос на другой лев el, и не решают проблему. Например, если вы запускаете несколько приложений, эти настройки, вероятно, повлияют и на другие приложения на том же сервере.
Кроме того, если вы видите, что люди пишут об идее / намерении распаковывать / редактировать / изменять / переупаковывать стандартные jar-файлы на сервере, пожалуйста, остановите их. Это ужасная идея. Он будет работать один раз для данного приложения, и тот, кто возьмет на себя управление проектом, сервером и т. Д. c. однажды попадется в эту ловушку и будет искать вечно. Кто бы мог подумать, что кто-то изменил стандартные файлы jar, предоставляемые сервером приложений. Возможно, прочитав этот комментарий здесь ...;)
Подобные проблемы, которые помогли:
Остающиеся вопросы:
- Можно ли автоматически определить файл jar, который предоставляет или конфликтующий пакет?