2013-07-25 7 views
1

У меня странная проблема с CDI/Weld, из-за которой я просто не могу найти решение.CDI/Weld Неудовлетворительные зависимости proglem

Я только что установил GlassFish 4 с целью переноса нашего основного продукта на него, но когда я пытаюсь его развернуть, я получаю трассировку стека, показанную ниже в файлах журнала (и она не используется).

Это зрелая заявка, используемая в производстве на GlassFish 3.1.x в нескольких местах, поэтому я знаю, что код хорош (по крайней мере, на JEE6 в любом случае).

Я действительно даже не знаю, с чего начать искать это, поскольку трассировка стека даже не приближается к моему коду. Я искал источник для класса ValidationInterceptor и, по-видимому, Validator, упомянутый в сообщениях об ошибке, имеет тип javax.validation.Validator, но это не помогает, поскольку у меня нет ничего, что реализует этот интерфейс в моем коде.

Спасибо за любые указания относительно того, где искать/как это исправить.

WARNING: The following warnings have been detected: WARNING: Parameter 1 of type javax.enterprise.inject.spi.Bean<?> from public static void org.apache.myfaces.extensions.cdi.jsf.impl.util.WeldCache.setBean(javax.enterprise.inject.spi.Bean<?>) is not resolvable to a concrete type. 

SEVERE: Exception during lifecycle processing 
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) 
Caused by: org.jboss.weld.exceptions.DeploymentException: 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.jboss.weld.bootstrap.Validator.validateInjectionPointForDeploymentProblems(Validator.java:403) 
    at org.jboss.weld.bootstrap.Validator.validateInjectionPoint(Validator.java:325) 
    at org.jboss.weld.bootstrap.Validator.validateInterceptor(Validator.java:554) 
    at org.jboss.weld.bootstrap.Validator.validateInterceptors(Validator.java:530) 
    at org.jboss.weld.bootstrap.Validator.validateDeployment(Validator.java:479) 
    at org.jboss.weld.bootstrap.WeldBootstrap.validateBeans(WeldBootstrap.java:536) 
    at org.glassfish.weld.WeldDeployer.event(WeldDeployer.java:216) 
    ... 36 more 

ответ

1

У меня была такая же проблема, как и у вас.

Я решил это путем удаления Apache MyFaces CODI из моего проекта, так как это кажется несовместимым с JEE7

Если вы используете Apache MyFaces CODI в проекте, это может быть причиной вашей проблемы

You можно найти дополнительную информацию Here

с уважением

+0

Я думаю, вы, вероятно, решить мою проблему, как я также использую CODI для @ViewAccessScoped, что позволит мне сэкономить много времени, устраняя библиотеки один за другим. Я проверю его, прежде чем отмечать это как принятое, если все в порядке. Кстати, если вы используете Guava, не обновляйтесь до последней версии V14, это также несовместимо с JEE7, V13 в порядке. – wobblycogs

+0

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

+0

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

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