WELD-001408 Неудовлетворительные зависимости для типа [Валидатор]

Я не могу развернуть свой проект после его переноса с Java EE 6 на Java EE 7.

У меня уже включен CDI (beans.xml с bean-discovery-mode="all" для обратной совместимости)

Ошибка развертывания, похоже, не связана с моим кодом, поскольку в нем упоминается класс «Валидатор», пытающийся быть внедренным в org.hibernate.validator.internal.cdi.interceptor.ValidationInterceptor.

Я понятия не имею, что здесь происходит.

Я использую GlassFish 4.0. Вот трассировка стека исключения, сгенерированного во время развертывания:

org.glassfish.deployment.common.DeploymentException: CDI deployment failure:WELD-001408 Unsatisfied dependencies for type [Validator] with qualifiers [@Default] at injection point [[UnbackedAnnotatedField] @Inject private org.hibernate.validator.internal.cdi.interceptor.ValidationInterceptor.validator]
at org.glassfish.weld.WeldDeployer.event(WeldDeployer.java:225)
at org.glassfish.kernel.event.EventsImpl.send(EventsImpl.java:131)
at org.glassfish.internal.data.ApplicationInfo.load(ApplicationInfo.java:328)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:493)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:219)
at org.glassfish.deployment.admin.DeployCommand.execute(DeployCommand.java:491)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2$1.run(CommandRunnerImpl.java:527)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2$1.run(CommandRunnerImpl.java:523)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.Subject.doAs(Subject.java:356)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2.execute(CommandRunnerImpl.java:522)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:546)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:1423)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.access$1500(CommandRunnerImpl.java:108)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1762)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1674)
at com.sun.enterprise.v3.admin.AdminAdapter.doCommand(AdminAdapter.java:534)
at com.sun.enterprise.v3.admin.AdminAdapter.onMissingResource(AdminAdapter.java:224)
at org.glassfish.grizzly.http.server.StaticHttpHandler.service(StaticHttpHandler.java:297)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:246)
at org.glassfish.grizzly.http.server.HttpHandler.runService(HttpHandler.java:191)
at org.glassfish.grizzly.http.server.HttpHandler.doHandle(HttpHandler.java:168)
at org.glassfish.grizzly.http.server.HttpServerFilter.handleRead(HttpServerFilter.java:189)
at org.glassfish.grizzly.filterchain.ExecutorResolver$9.execute(ExecutorResolver.java:119)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(DefaultFilterChain.java:288)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:206)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:136)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:114)
at org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:77)
at org.glassfish.grizzly.nio.transport.TCPNIOTransport.fireIOEvent(TCPNIOTransport.java:838)
at org.glassfish.grizzly.strategies.AbstractIOStrategy.fireIOEvent(AbstractIOStrategy.java:113)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.run0(WorkerThreadIOStrategy.java:115)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.access$100(WorkerThreadIOStrategy.java:55)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy$WorkerThreadRunnable.run(WorkerThreadIOStrategy.java:135)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:564)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.run(AbstractThreadPool.java:544)
at java.lang.Thread.run(Thread.java:722)

java-ee-6 cdi jakarta-ee java-ee-7 glassfish-4
person Juan    schedule 31.07.2013    source источник
comment
Это ВОЙНА или УХО? Мое первое предположение заключается в том, что это связано с вашими изменениями в файле beans.xml, поскольку Weld теперь собирает вещи, которых раньше, вероятно, не было.   -  person LightGuard    schedule 31.07.2013

Ответы (2)


arrow_upward
4
arrow_downward

Я тоже это вижу, плюс очень похожая проблема с Guava 14.0.1.

Основная причина этого, по-видимому, заключается в том, что поведение CDI по умолчанию изменилось с 1.0 на 1.1. В версии 1.0 CDI не делал ничего с архивом, если не присутствовал файл beans.xml. В версии 1.1 отсутствующий файл beans.xml эквивалентен файлу с bean-discovery-mode=annotated.

Другими словами, если в вашем архиве есть какие-либо библиотеки, которые используют аннотации внедрения CDI, но не содержат beans.xml, они теперь будут инициировать попытки внедрения.

person HansMari    schedule 10.10.2013

arrow_upward
1
arrow_downward

После нескольких часов тестирования этой проблемы я пришел к выводу, что она связана с проблемой несовместимости между Apache MyFaces CODI (расширение CDI) и Java EE 7. Вы можете проверить это самостоятельно, создав пустой проект Java EE 7 (Netbeans + Glassfish 4.0) и добавив библиотеку, их последний релиз можно загрузить с здесь

Я использовал это расширение из-за его реализации @ViewAccessScoped. Я заменил его новой аннотацией JSF 2.2 javax.faces.view.ViewScoped, которая фактически работает с CDI.

person Juan    schedule 31.07.2013
comment
Извините, но этот ответ не очень полезен. Просто не добавляйте модуль Bean-Validation из CODI. Большая часть его функций доступна в EE7 «из коробки». - person Dar Whi; 02.08.2013
comment
У других не было проблем с этим. См., например. комментарий в последней части jsfcorner.blogspot.co .at/2013/08/from-codi-to-deltaspike.html - person Dar Whi; 06.08.2013