java ee - CDI Inject fails on maven-embedded-glassfish-plugin -- org.jboss.weld.exceptions.DeploymentException: WELD-001408 Unsatisfied dependencies for type -

we have webapp, being developed using java ee 7, jsf 2.2 , glassfish 4.0. there 2 particular managed beans circular dependency.

usuariocontroller

@named @sessionscoped public class usuariocontroller implements serializable {      /** snipet **/      @inject     private enderecocontroller enderecocontroller;      /** snipet **/ } 

enderecocontroller

@named @viewscoped public class enderecocontroller {      /** snipet **/      @inject     private usuariocontroller esuariocontroller;      /** snipet **/ } 

when webapp packaged , deployed normal glassfish 4.0 installation, works fine.

however, during development use maven-embedded-glassfish test locally inside ide. , app deployment fails following exception.

severe: exception while loading app : cdi deployment failure:weld-001408 unsatisfied dependencies type [enderecocontroller] qualifiers [@default] @ injection point [[backedannotatedfield] @inject private net.jhm.exemplo.view.usuariocontroller.enderecocontroller] org.jboss.weld.exceptions.deploymentexception: weld-001408 unsatisfied dependencies type [enderecocontroller] qualifiers [@default] @ injection point [[backedannotatedfield] @inject private net.jhm.exemplo.view.usuariocontroller.enderecocontroller]     @ org.jboss.weld.bootstrap.validator.validateinjectionpointfordeploymentproblems(validator.java:403)     @ org.jboss.weld.bootstrap.validator.validateinjectionpoint(validator.java:325)     @ org.jboss.weld.bootstrap.validator.validategeneralbean(validator.java:177)     @ org.jboss.weld.bootstrap.validator.validateribean(validator.java:208)     @ org.jboss.weld.bootstrap.validator.validatebean(validator.java:519)     @ org.jboss.weld.bootstrap.validator.validatebeans(validator.java:505)     @ org.jboss.weld.bootstrap.validator.validatedeployment(validator.java:480)     @ org.jboss.weld.bootstrap.weldbootstrap.validatebeans(weldbootstrap.java:536)     @ org.glassfish.weld.welddeployer.event(welddeployer.java:216)     @ 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.admin.cli.embeddable.deployerimpl.deploy(deployerimpl.java:133)     @ com.sun.enterprise.admin.cli.embeddable.deployerimpl.deploy(deployerimpl.java:109)     @ org.glassfish.maven.pluginutil.dodeploy(pluginutil.java:108)     @ sun.reflect.nativemethodaccessorimpl.invoke0(native method)     @ sun.reflect.nativemethodaccessorimpl.invoke(nativemethodaccessorimpl.java:57)     @ sun.reflect.delegatingmethodaccessorimpl.invoke(delegatingmethodaccessorimpl.java:43)     @ java.lang.reflect.method.invoke(method.java:606)     @ org.glassfish.maven.abstractdeploymojo.dodeploy(abstractdeploymojo.java:259)     @ org.glassfish.maven.deploymojo.execute(deploymojo.java:69)     @ org.apache.maven.plugin.defaultbuildpluginmanager.executemojo(defaultbuildpluginmanager.java:101)     @ org.apache.maven.lifecycle.internal.mojoexecutor.execute(mojoexecutor.java:209)     @ org.apache.maven.lifecycle.internal.mojoexecutor.execute(mojoexecutor.java:153)     @ org.apache.maven.lifecycle.internal.mojoexecutor.execute(mojoexecutor.java:145)     @ org.apache.maven.lifecycle.internal.lifecyclemodulebuilder.buildproject(lifecyclemodulebuilder.java:84)     @ org.apache.maven.lifecycle.internal.lifecyclemodulebuilder.buildproject(lifecyclemodulebuilder.java:59)     @ org.apache.maven.lifecycle.internal.lifecyclestarter.singlethreadedbuild(lifecyclestarter.java:183)     @ org.apache.maven.lifecycle.internal.lifecyclestarter.execute(lifecyclestarter.java:161)     @ org.apache.maven.defaultmaven.doexecute(defaultmaven.java:320)     @ org.apache.maven.defaultmaven.execute(defaultmaven.java:156)     @ org.apache.maven.cli.mavencli.execute(mavencli.java:537)     @ org.apache.maven.cli.mavencli.domain(mavencli.java:196)     @ org.apache.maven.cli.mavencli.main(mavencli.java:141)     @ sun.reflect.nativemethodaccessorimpl.invoke0(native method)     @ sun.reflect.nativemethodaccessorimpl.invoke(nativemethodaccessorimpl.java:57)     @ sun.reflect.delegatingmethodaccessorimpl.invoke(delegatingmethodaccessorimpl.java:43)     @ java.lang.reflect.method.invoke(method.java:606)     @ org.codehaus.plexus.classworlds.launcher.launcher.launchenhanced(launcher.java:290)     @ org.codehaus.plexus.classworlds.launcher.launcher.launch(launcher.java:230)     @ org.codehaus.plexus.classworlds.launcher.launcher.mainwithexitcode(launcher.java:409)     @ org.codehaus.plexus.classworlds.launcher.launcher.main(launcher.java:352)  aug 07, 2013 12:22:31 pm pluginutil dodeploy info: deployed null 

would able resolving our development environment? several people prefer embedded glassfish plugin complete server local development.

seems dependency/classpath issue related maven-embedded-glassfish in particular, have no clue begin. it's been difficult find explanations cdi weld-nnnnnn exceptions around google.

well, after searching , reading resolved it. turns out, webapp developed java ee 6, , decision made use java ee 7 along way. well... somethings different in java ee 7. handles managed bean scopes differently. 1 thing, @viewscoped annotation not mentioned in java ee 7 docs anymore (there new @flowscoped, still reading on that). bumped log level finest , scoured through endless lines of details understand happened.

in order working code today, had understand key difference on cdi implementation. until java ee 6, cdi scan packages , beans considered container. behavior apparently changed java ee 7, in way classes annotated specific scope considered becoming managed beans. in other words, @named annotation needs accompanied 1 of scope annotations (@requestscoped, @sessionscoped, @dependentscoped, @flowscoped, etc). since @viewscoped no longer part of official scope list, class enderecocontroller not become managed bean when cdi boots. trying inject instance usuariocontroller results in generic weld dependency exception because instance of bean never created.

to things working in portability, had change web-ibnf/beans.xml file change attribute bean-discovery-mode="annotated" bean-discovery-mode="all".

<?xml version="1.0" encoding="utf-8"?> <beans xmlns="http://xmlns.jcp.org/xml/ns/javaee"        xmlns:xsi="http://www.w3.org/2001/xmlschema-instance"        xsi:schemalocation="http://xmlns.jcp.org/xml/ns/javaee http://xmlns.jcp.org/xml/ns/javaee/beans_1_1.xsd"        bean-discovery-mode="all"> </beans> 

using all discovery mode causes cdi include classes consideration while scanning managed beans, including ones not have cdi scope annotation. underway understand new scope management better adapt code java ee 7 standards.

i still find strange enough original code works within complete glassfish install not inside maven-embedded-glassfish-plugin.

my personal rant java ee/cdi

also, explicitly comment on absurdly broad description given weld-001408 unsatisfied dependency stacktrace. message means cdi unable provide dependency injection. no details on type of error caused injected bean not created in first place. not "sorry, unable find bean instantiate".

an unsatisfied dependency can occur various reasons. exception occurs while trying instantiate dependency hidden away log files. might spend hour until realize bean's constructor throwing nullpointerexception. exception wrapping nonsense reason why searching error message on google results in ocean of people having same error due different causes.

i hope improve error handling, raising exception messages can understand better why particular dependency cannot satisfied.