1

I have a strange CDI / Weld issue that I just can't figure out a solution for.

I've just installed GlassFish 4 with the intention of moving our main product over to it but when I try to deploy it I get the stack trace shown below in the log files (and it fails to deploy).

This is a mature application used in production on GlassFish 3.1.x in several locations so I know the code is good (at least on JEE6 anyway).

I really don't even know where to begin looking for this as the stack trace doesn't even go near any of my code. I've looked up the source for the ValidationInterceptor class and apparently the Validator mentioned in the error messages is of type javax.validation.Validator but that doesn't help as I have nothing that implements that interface in my code.

Thanks for any pointers regarding where to look / how to fix this.

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
Seb
  • 1,721
  • 1
  • 17
  • 30
wobblycogs
  • 4,083
  • 7
  • 37
  • 48

1 Answers1

1

I had exactly the same problem than you.

I resolved this by removing Apache MyFaces CODI from my project since it seems to be incompatible with JEE7

If you are using Apache MyFaces CODI in your project this could be the cause of your problem

You can find additional info Here

Regards

Community
  • 1
  • 1
Juan
  • 467
  • 1
  • 5
  • 19
  • I think you've probably solved my problem as I'm also using CODI for @ViewAccessScoped, that'll save me a lot of time eliminating libraries one by one. I'll test it before marking this as accepted if that's ok. By the way, if you are using Guava don't upgrade to the latest V14 release it is also incompatible with JEE7, V13 is ok. – wobblycogs Aug 01 '13 at 08:20
  • @Juan Sorry, but that answer isn't very useful. Just don't add the Bean-Validation module from CODI. The majority of its functionality is available in EE7 out-of-the-box. – Dar Whi Aug 02 '13 at 12:32
  • Others had no issue with doing it. See e.g. the comment in the last part of http://jsfcorner.blogspot.co.at/2013/08/from-codi-to-deltaspike.html – Dar Whi Aug 06 '13 at 10:52