Jakarta ee WELD-001408未满足[验证程序]类型的依赖关系

在将项目从JavaEE6迁移到JavaEE7之后，我无法部署它

我已经启用了CDI（beans.xml和bean discovery mode=“all”实现向后兼容性）

部署错误似乎与我的代码无关，因为它提到一个“Validator”类试图在

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)

在对这个问题进行了几个小时的测试之后，我得出结论，它与apachemyfacescodi（CDI扩展）和javaee7之间的不兼容问题有关。您可以通过创建一个空的JavaEE7项目（Netbeans+Glassfish 4.0）并添加库来自己测试它，它们的最新版本可以从

我之所以使用这个扩展是因为它的@ViewAccessScope实现。我用新的JSF2.2注释javax.faces.view.ViewScoped代替了它，它实际上与CDI一起工作，我也看到了这一点，加上Guava 14.0.1的一个非常类似的问题

其根本原因似乎是CDI的默认行为从1.0更改为1.1。在1.0中，除非存在beans.xml，否则CDI不会对归档文件进行任何处理。在1.1中，缺少的beans.xml相当于带有bean发现模式=注释的beans.xml

换句话说，如果您的存档中有任何库使用CDI注入注释，但不包含beans.xml，那么这些库现在将触发注入尝试。
这是战争还是EAR？我的第一个猜测是，这与您在beans.xml文件中所做的更改有关，因为Weld现在正在收集以前可能没有的东西。对不起，这个答案不是很有用。只是不要从CODI添加Bean验证模块。它的大部分功能在EE7开箱即用中提供，其他人对此没有问题。例如，参见本手册最后一部分中的注释