Injection CDI échoue sur maven-embedded-glassfish-plugin - org.jboss.weld.exceptions.DeploymentException: WELD-001408 Dépendances insatisfaites pour le type
Nous avons une webapp, actuellement en cours de développement à l'aide de Java EE 7, JSF 2.2 et Glassfish 4.0. Il y a deux notamment géré les grains avec une dépendance circulaire.
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 **/
}Lors de la webapp est emballé et a déployé normal de glassfish 4.0 installation, il fonctionne très bien.
Cependant, au cours du développement, nous utilisons maven-embedded-glassfish pour tester localement à l'intérieur de l'IDE. Et le déploiement des applications échoue avec l'exception suivante.
SEVERE: Exception while loading the app : CDI deployment failure:WELD-001408 Unsatisfied dependencies for type [EnderecoController] with qualifiers [@Default] at injection point [[BackedAnnotatedField] @Inject private net.jhm.exemplo.view.UsuarioController.enderecoController]
org.jboss.weld.exceptions.DeploymentException: WELD-001408 Unsatisfied dependencies for type [EnderecoController] with qualifiers [@Default] at injection point [[BackedAnnotatedField] @Inject private net.jhm.exemplo.view.UsuarioController.enderecoController]
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.validateGeneralBean(Validator.java:177)
at org.jboss.weld.bootstrap.Validator.validateRIBean(Validator.java:208)
at org.jboss.weld.bootstrap.Validator.validateBean(Validator.java:519)
at org.jboss.weld.bootstrap.Validator.validateBeans(Validator.java:505)
at org.jboss.weld.bootstrap.Validator.validateDeployment(Validator.java:480)
at org.jboss.weld.bootstrap.WeldBootstrap.validateBeans(WeldBootstrap.java:536)
at org.glassfish.weld.WeldDeployer.event(WeldDeployer.java:216)
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.admin.cli.embeddable.DeployerImpl.deploy(DeployerImpl.java:133)
at com.sun.enterprise.admin.cli.embeddable.DeployerImpl.deploy(DeployerImpl.java:109)
at org.glassfish.maven.PluginUtil.doDeploy(PluginUtil.java:108)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at org.glassfish.maven.AbstractDeployMojo.doDeploy(AbstractDeployMojo.java:259)
at org.glassfish.maven.DeployMojo.execute(DeployMojo.java:69)
at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
at org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:320)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537)
at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:141)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290)
at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230)
at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409)
at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352)
Aug 07, 2013 12:22:31 PM PluginUtil doDeploy
INFO: Deployed nullQuelqu'un serait-il en mesure d'aider à la résolution de ce pour notre environnement de développement? Plusieurs personnes préfèrent la glassfish embarqué plugin pour un serveur complet pour le développement local.
Semble comme une dépendance/classpath problème lié à maven-embedded-glassfish en particulier, mais nous n'avons pas la moindre idée par où commencer. Il a été un peu difficile à trouver des explications pour le CDI de SOUDURE-NNNNNN exceptions autour de Google.
source d'informationauteur JulioHM | 2013-08-07
Vous devez vous connecter pour publier un commentaire.
Bien, après beaucoup de recherches et de lecture, nous avons enfin résolu. S'avère, la webapp a été initialement développé pour Java EE 6, et une décision a été prise d'utiliser Java EE 7 le long de la voie. Eh bien... il y a des choses sont différentes dans Java EE 7. Il gère managed bean étendues différemment. Pour une chose, la
@ViewScopedannotation n'est même pas mentionné dans le Java EE 7 docs plus (il y a un nouveau@FlowScopedmais nous sommes encore à la lecture). Nous avons augmenté le niveau de log de plus belle et parcouru par d'interminables lignes de détails pour comprendre ce qui s'est passé.Afin de le faire fonctionner avec le code tel qu'il est aujourd'hui, nous avons dû comprendre une différence fondamentale sur le CDI de mise en œuvre. Jusqu'à Java EE 6, CDI numériser tous les forfaits et tous les haricots, serait examiné par le conteneur. Ce comportement apparemment changé avec Java EE 7, de façon à ce que seules les classes annotées avec un champ d'application spécifique sont considérés pour devenir réussi haricots. En d'autres termes, la
@Namedannotation doit être accompagné par l'un de la portée des annotations (@RequestScoped@SessionScoped@DependentScoped@FlowScopedetc). Depuis@ViewScopedn'est plus de la partie officielle de la liste étendue, la classeEnderecoControllerne devienne pas un managed bean lors de la CDI bottes. Essaie d'injecter une instance enUsuarioControllerrésultats dans un générique de SOUDURE dépendance à l'exception parce qu'une instance du bean n'a jamais été créé.Pour obtenir des choses de travail à l'arrière de la portabilité, nous avons dû changer le
WEB-IBNF/beans.xmlfichier pour modifier l'attributbean-discovery-mode="annotated"àbean-discovery-mode="all".À l'aide de la
allmode de découverte des causes de la CDI, pour inclure toutes les classes pour considération lors de la numérisation à la gestion des haricots, y compris ceux qui n'ont pas de CDI champ d'application de l'annotation. Nous sommes maintenant en cours pour comprendre la nouvelle gestion de la portée du mieux adapter le code pour Java EE 7 normes.Je trouve toujours ça assez étrange que le code d'origine travaille au sein d'un complet glassfish installer, mais pas à l'intérieur de maven-embedded-glassfish-plugin.
Mon coup de gueule à propos de Java EE/CDI
Aussi, je voudrais explicitement commentaire sur l'univers vaste description donnée par le de SOUDURE-001408 Insatisfaits de dépendance stacktrace. Le message signifie simplement que la CDI a été incapable de fournir une injection de dépendance. Pas de précisions sur ce type d'erreur a provoqué l'injection de fève de ne PAS être créé en premier lieu. Même pas un "désolé, impossible de trouver de la fève à instancier".
Un insatisfait de la dépendance peut se produire pour diverses raisons. Toute exception qui se produit lors de l'instanciation de la dépendance est caché de fichiers de log. Vous pouvez passer une heure jusqu'à ce que vous vous rendez compte de votre bean constructeur est en train de jeter un
NullPointerException. Cette exception d'emballage non-sens est la raison pour laquelle la recherche de ce message d'erreur sur les résultats de Google dans un océan de personnes ayant la même erreur due à différentes causes.J'espère qu'ils vont améliorer la gestion des erreurs, soulevant l'exception des messages afin que nous puissions mieux comprendre POURQUOI certains de dépendance ne peut être satisfaite.