Utilisez CDI.
Selon JSF 2.3, @ManagedBean est obsolète . Voir également le numéro de spécification 1417 . Cela signifie que il n'y a pas plus d' une raison de choisir @ManagedBeanplus @Named. Cela a été implémenté pour la première fois dans la version bêta de Mojarra 2.3.0 m06.
L'histoire
La principale différence est qu'elle @ManagedBeanest gérée par le framework JSF et n'est @ManagedPropertydisponible que via un autre beans gérés JSF. @Namedest géré par le serveur d'application (le conteneur) via le framework CDI et est @Injectdisponible pour tout type d'artefact géré par conteneur comme @WebListener,@WebFilter , @WebServlet, @Path, @Stateless, etc. et même un JSF @ManagedBean. De l'autre côté, @ManagedPropertyne fonctionne pas dans un @Namedou tout autre artefact géré par conteneur. Cela ne fonctionne vraiment qu'à l'intérieur @ManagedBean.
Une autre différence est que CDI injecte en fait des proxys déléguant à l'instance actuelle dans la portée cible sur une base par requête / thread (comme la façon dont les EJB sont injectés). Ce mécanisme permet d'injecter un bean de portée plus étroite dans un bean de portée plus large, ce qui n'est pas possible avec JSF @ManagedProperty. JSF "injecte" ici l'instance physique directement en invoquant un setter (c'est aussi exactement pourquoi un setter est nécessaire, alors que ce n'est pas obligatoire avec @Inject).
Bien que ce ne soit pas directement un inconvénient - il existe d'autres moyens - la portée de @ManagedBeanest simplement limitée. D'un autre point de vue, si vous ne voulez pas exposer "trop" pour @Inject, vous pouvez aussi simplement conserver vos beans gérés @ManagedBean. C'est comme protectedcontre public. Mais cela ne compte pas vraiment.
Au moins, dans JSF 2.0 / 2.1, le principal inconvénient de la gestion des backing beans JSF par CDI est qu'il n'y a pas d'équivalent CDI de @ViewScoped. Le @ConversationScopedse rapproche, mais nécessite toujours un démarrage et un arrêt manuels et ajoute un cidparamètre de demande laid aux URL de résultat. MyFaces CODI facilite les choses en reliant de manière totalement transparente les JSF javax.faces.bean.ViewScopedà CDI afin que vous puissiez simplement le faire @Named @ViewScoped, mais cela ajoute un vilainwindowId paramètre de requête aux URL de résultat, également sur la navigation simple de page à page. OmniFaces résout tout cela avec un vrai CDI @ViewScopedqui lie vraiment la portée du bean à l'état de vue JSF plutôt qu'à un paramètre de requête arbitraire.
JSF 2.2 (qui sort 3 ans après cette question / réponse) offre une nouvelle @ViewScopedannotation entièrement compatible CDI prête à l'emploi dans la saveur de javax.faces.view.ViewScoped. JSF 2.2 est même livré avec un CDI uniquement @FlowScopedqui n'a pas d' @ManagedBeanéquivalent, poussant ainsi les utilisateurs JSF vers CDI. On s'attend à ce que les @ManagedBeanamis soient obsolètes selon Java EE 8. Si vous l'utilisez toujours @ManagedBean, il est donc fortement recommandé de passer à CDI pour être préparé aux futurs chemins de mise à niveau. CDI est facilement disponible dans des conteneurs compatibles Java EE Web Profile, tels que WildFly, TomEE et GlassFish. Pour Tomcat, vous devez l'installer séparément, exactement comme vous l'avez déjà fait pour JSF. Voir aussi Comment installer CDI dans Tomcat?