2013-07-31 4 views
4

Я не смог развернуть свой проект после переноса его из Java EE 6 в Java EE 7.WELD-001408 Невыполненных зависимости для типа [Validator]

У меня уже есть CDI включен (beans.xml с бобом-открытием -mode = «все» для обратной совместимости)

ошибка развертывания, кажется, не быть связано с моим кодом, поскольку он упоминает класс «Оценщик» пытается быть введен в 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) 
+0

Это ВОЙНА или УХОД? Моя первая догадка заключается в том, что это связано с вашими изменениями в файле beans.xml, поскольку Weld теперь собирает вещи, которые, вероятно, не были бы раньше. – LightGuard

ответ

1

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

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

+0

Извините, но этот ответ не очень полезен. Просто не добавляйте модуль проверки Bean из CODI. Большинство его функциональных возможностей доступно в EE7 из готового продукта –

+0

Другие не имели проблемы с этим. См. комментарий в последней части http://jsfcorner.blogspot.co.at/2013/08/from-codi-to-deltaspike.html –

3

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

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

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

Смежные вопросы