java ee - WELD-001408 Unsatisfied dependencies for type [Validator] -


i'm unable deploy project after migrating java ee 6 java ee 7.

i have cdi enabled (beans.xml bean-discovery-mode="all" backwards compatibility)

the deployment error not seem related code since mentions "validator" class trying injected @ org.hibernate.validator.internal.cdi.interceptor.validationinterceptor

i don't have clue of going on here.

i'm using glassfish 4.0. here's stack trace of exception generated @ deployment time:

org.glassfish.deployment.common.deploymentexception: cdi deployment failure:weld-001408 unsatisfied dependencies type [validator] qualifiers [@default] @ injection point [[unbackedannotatedfield] @inject private org.hibernate.validator.internal.cdi.interceptor.validationinterceptor.validator] @ org.glassfish.weld.welddeployer.event(welddeployer.java:225) @ org.glassfish.kernel.event.eventsimpl.send(eventsimpl.java:131) @ org.glassfish.internal.data.applicationinfo.load(applicationinfo.java:328) @ com.sun.enterprise.v3.server.applicationlifecycle.deploy(applicationlifecycle.java:493) @ com.sun.enterprise.v3.server.applicationlifecycle.deploy(applicationlifecycle.java:219) @ org.glassfish.deployment.admin.deploycommand.execute(deploycommand.java:491) @ com.sun.enterprise.v3.admin.commandrunnerimpl$2$1.run(commandrunnerimpl.java:527) @ com.sun.enterprise.v3.admin.commandrunnerimpl$2$1.run(commandrunnerimpl.java:523) @ java.security.accesscontroller.doprivileged(native method) @ javax.security.auth.subject.doas(subject.java:356) @ com.sun.enterprise.v3.admin.commandrunnerimpl$2.execute(commandrunnerimpl.java:522) @ com.sun.enterprise.v3.admin.commandrunnerimpl.docommand(commandrunnerimpl.java:546) @ com.sun.enterprise.v3.admin.commandrunnerimpl.docommand(commandrunnerimpl.java:1423) @ com.sun.enterprise.v3.admin.commandrunnerimpl.access$1500(commandrunnerimpl.java:108) @ com.sun.enterprise.v3.admin.commandrunnerimpl$executioncontext.execute(commandrunnerimpl.java:1762) @ com.sun.enterprise.v3.admin.commandrunnerimpl$executioncontext.execute(commandrunnerimpl.java:1674) @ com.sun.enterprise.v3.admin.adminadapter.docommand(adminadapter.java:534) @ com.sun.enterprise.v3.admin.adminadapter.onmissingresource(adminadapter.java:224) @ org.glassfish.grizzly.http.server.statichttphandler.service(statichttphandler.java:297) @ com.sun.enterprise.v3.services.impl.containermapper.service(containermapper.java:246) @ org.glassfish.grizzly.http.server.httphandler.runservice(httphandler.java:191) @ org.glassfish.grizzly.http.server.httphandler.dohandle(httphandler.java:168) @ org.glassfish.grizzly.http.server.httpserverfilter.handleread(httpserverfilter.java:189) @ org.glassfish.grizzly.filterchain.executorresolver$9.execute(executorresolver.java:119) @ org.glassfish.grizzly.filterchain.defaultfilterchain.executefilter(defaultfilterchain.java:288) @ org.glassfish.grizzly.filterchain.defaultfilterchain.executechainpart(defaultfilterchain.java:206) @ org.glassfish.grizzly.filterchain.defaultfilterchain.execute(defaultfilterchain.java:136) @ org.glassfish.grizzly.filterchain.defaultfilterchain.process(defaultfilterchain.java:114) @ org.glassfish.grizzly.processorexecutor.execute(processorexecutor.java:77) @ org.glassfish.grizzly.nio.transport.tcpniotransport.fireioevent(tcpniotransport.java:838) @ org.glassfish.grizzly.strategies.abstractiostrategy.fireioevent(abstractiostrategy.java:113) @ org.glassfish.grizzly.strategies.workerthreadiostrategy.run0(workerthreadiostrategy.java:115) @ org.glassfish.grizzly.strategies.workerthreadiostrategy.access$100(workerthreadiostrategy.java:55) @ org.glassfish.grizzly.strategies.workerthreadiostrategy$workerthreadrunnable.run(workerthreadiostrategy.java:135) @ org.glassfish.grizzly.threadpool.abstractthreadpool$worker.dowork(abstractthreadpool.java:564) @ org.glassfish.grizzly.threadpool.abstractthreadpool$worker.run(abstractthreadpool.java:544) @ java.lang.thread.run(thread.java:722) 

i'm seeing well, plus similar problem guava 14.0.1.

the root cause of seems default behaviour of cdi changed 1.0 1.1. in 1.0, cdi didn't anything archive unless beans.xml present. in 1.1, missing beans.xml equivalent 1 bean-discovery-mode=annotated.

in other words, if have libraries in archive make use of cdi injection annotations contain no beans.xml, these trigger injection attempts.


Comments

Popular posts from this blog

c++ - Creating new partition disk winapi -

Android Prevent Bluetooth Pairing Dialog -

php - joomla get content in onBeforeCompileHead function -