@ManagedBeans sont obsolètes dans JavaEE6 à cause de la @Named en CDI/soudure ?

Question

En raison de la CDI (et sa mise en œuvre de soudure), chaque POJO en JEE6 peut être annotée avec des `` , qui rend le POJO accessible à la vue.

Cela signifie-t-il que les ManagedBeans sont complètement obsolètes maintenant ? Ou ai-je manqué quelque chose où `` est toujours logique ?

Answer 1

En bref, @ManagedBean de sens que pour les applications qui utilisent JSF, mais ne pas utiliser la JSR 299 (quelle que soit la raison). Ci-dessous une explication plus longue de Gavin King:

Re: Comparaisons @ManagedBean annotations dans JSF2?:

Tout en regardant à travers la Soudure des exemples, et les plus âgés WebBeans de la documentation, il ressemble à un concurrent pour le nouveau @ManagedBean JSF 2.0 annotations. Est-il lorsque nous voulez les utiliser l'un sur l'autre?

C'est une bonne question, et je ne suis pas vraiment en plein accord avec le les réponses qui ont été publiés jusqu'à présent.

Le nouveau EE Réussi Haricots spécification définit un composant de base modèle pour Java EE, avec un très de base ensemble de services pour les conteneurs (@Resource, @PostConstruct, @PreDestroy).

L'idée est que d'autres spécifications (début avec EJB, CDI, JSF et le Java Intercepteurs spec) appuyer sur ce composant de base du modèle et de la couche des services supplémentaires, par exemple la gestion des transactions, typesafe l'injection de dépendance, les intercepteurs. Donc à ce niveau, la gestion de haricots, CDI, les intercepteurs et les spécifications EJB tous travaillent main dans la main et sont très complémentaires.

Maintenant, la gestion de Haricots spécification est tout à fait ouvert à l'égard de identifier exactement les classes sont géré haricots. Il fournit le @ManagedBean d'annotation comme un mécanisme, mais il permet aussi à d'autres spécifications pour définir les différents les mécanismes. Ainsi, par exemple:

• La spécification EJB dit qu'une classe d'obéir à certaines émissions restrictions @Statelessou @Stateful d'annotation déployé dans une Jar EJB est un managed bean.

• Le CDI spécification indique qu'une classe avec un constructeur approprié déployé dans un "haricot de déploiement archive" est un managed bean.

Étant donné que les EJB et CDI fournir sans doute des moyens plus commodes pour identifier un managed bean, vous pourriez me demande justement ce qu' @ManagedBeanest nécessaire pour. La réponse, comme nous le soulignions par Dan, c'est que si vous avez des CDI disponible dans votre environnement (par exemple, si vous utilisez EE6), puis @ManagedBean est tout simplement pas vraiment nécessaire. @ManagedBean est vraiment là pour une utilisation par des personnes qui sont à l'aide de JSF2 sans CDI.

Otoh, que, si vous ne annoter un haricot @ManagedBean, et vous avez en CDI dans votre environnement, vous pouvez toujours utiliser CDI à injecter des trucs dans votre bean. C'est juste que l' @ManagedBean annotation n'est pas nécessaire dans ce cas.

Pour résumer, si vous avez des CDI disponible pour vous, il fournit une mesure supérieur modèle de programmation pour la @ManagedBean/@ManagedPropertymodèle que JSF2 hérite de JSF1. Donc supérieure, en fait, que l'EE 6 web le profil n'a pas besoin de support pour @ManagedProperty etc. L'idée étant que vous devriez simplement utiliser le CDI à la place.

Answer 2

Vous avez le choix. Utilisez le @ManagedBean de JSF2 à lier les haricots dans vos formulaires, ou utilisez l’annotation @Named de CDI. Si vous prévoyez faire seulement JSF, vous pouvez coller à @ManagedBean, mais si vous voulez intégrer avec EJB, ou faire usage du CDI de @ConversationScoped, puis aller sur la route CDI.

Personnellement, je pense que la prochaine version du JSF doit déprécier le @ManagedBean et standardiser sur CDI. La dualité est source de confusion pour les nouveaux arrivants.

Answer 3

Le CDI n'a pas de portée de vue, parce qu'il n'ont pas la notion de vue, donc si vous avez besoin de cette portée, CDI, dans sa forme pure ne peut pas le faire. L'étendue de l'affichage signifie fondamentalement la demande portée + étant AJAX-prêt. C'est pas une vue JSF, comme une page nommée xyz.xhtml, même si vous voyez JSF <f:viewParam> et l'aime. Une utilisation fréquente de cas avec vue étendue de haricots est comment obtenir les paramètres GET dans une telle bean. Aussi lire ceci.

Notez que le CDI vit plutôt à l'EJB/couche de service que le JSF/couche de présentation. Ce blog a une belle vue d'ensemble.

Comme tel, @ManagedBean ne peut pas être entièrement remplacé par la CDI, à nouveau si vous utilisez @ViewScoped des haricots, du moins pas sans l'extension de CDI ou de l'utilisation de la Couture 3 Faces module. À l'aide de la vue étendue de haricots est presque toujours à se produire lors de l'utilisation de AJAXed JSF 2-kits graphiques basé sur, comme RichFaces, PrimeFaces, IceFaces, etc.

Le mélange des annotations de la mauvaise Java EE 6 paquets peuvent obtenir en difficulté de façon inattendue, de nouveau lors de l'utilisation de RichFaces ou un analogue de l'API:

@javax.faces.bean.ManagedBean
@javax.faces.bean.[Jsf]Scoped

sont pour les composants utilisés uniquement à la couche de présentation, ici par RichFaces, PrimeFaces, etc. Certains composants riches semblent avoir des problèmes avec le CDI annotée et JSF-annoté helper haricots. Si vous obtenez une étrange comportement de vos haricots (ou des haricots qui semblent ne servir à rien) le mauvais mélange des annotations peut être la cause.

Le mélange JSF et CDI, comme

@javax.inject.Named
@javax.faces.bean.[Jsf]Scoped

est possible et fonctionne dans la plupart des cas lorsqu'ils sont référencés à partir de pages JSF, cependant, il ya certaines peu connues questions/inconvénients, par exemple, lors de l' utilisation d'un champ d'application JSF qui CDI n'a pas:

Aussi la combinaison @Named @ViewScoped ne fonctionne pas comme prévu. Dans le cadre du programme spécifique @ViewScoped fonctionne en combinaison avec la JSF-spécifique @ManagedBean seulement. Votre CDI-spécifique @Named va se comporter comme @RequestScoped de cette façon. Utiliser @ManagedBean au lieu de @Named ou l'utilisation CDI-spécifique @ConversationScoped au lieu de @ViewScoped.

Alors

@javax.inject.Named
@javax.faces.bean.[Cdi]Scoped

peut être utilisé pour le CDI haricots directement référencé à partir de vos pages JSF autant que je sache. Je n'ai pas eu de problèmes avec les combinaisons ci-dessus, jusqu'à présent, de sorte que vous pourriez envisager @ManagedBean obsolète ici.

Ce qui est à gauche est la couche de service, ici essentiellement de nature transactionnelle de l'EJB service de haricots déclaré que

@javax.ejb.*

la plupart @javax.ejb.Apatrides. Vous pouvez même les annoter et de l'utilisation des Ejb directement à partir de pages JSF - si je ne suis pas sûr si cela est souhaitable. De référence (injecter) tous les composants annotée avec @javax.ejb.*, par exemple, @Stateless, préfèrent @Inject sur @EJB , comme décrit ici. (Probablement un ancêtre de cette réponse...)

Enfin, une très belle présentation de Java EE 6, les annotations peuvent être trouvés ici: http://www.physics.usyd.edu.au/~rennie/javaEEReferenceSheet.html

Remarque: ce qui précède n'est pas d'info d'un expert, mais tout simplement mon propre/la vue à partir d'un point de vue des nouveaux arrivants sur cette ridiculement confusion Java EE 6 annotations spaghetti. Plus de perspicacité n'est pas encore élaboré. J'espère que cette réponse peut supporter d'être un général, la réponse pratique à cette confusion - même si il est allé un peu trop loin dans le contexte de la question d'origine.

Answer 4

Comme je Viens de le lire dans la Soudure de Référence (p. 12), @ManagedBean est maintenant superflu:

Vous pouvez déclarer explicitement un gérés bean annoter la classe d'haricot @ManagedBean, mais en CDI vous n'avez pas besoin d'. Selon l' spécification, le conteneur CDI traite toute la classe qui satisfait aux conditions suivantes sont gérés bean:

• Ce n'est pas un non-statique à l'intérieur de la classe. C'est un béton de classe, ou est annotée @Décorateur.
• Il n'est pas annoté avec un composant EJB-la définition de l'annotation ou déclarées comme un EJB classe d'haricot dans ejb-jar.xml.
• Il ne met pas en œuvre javax.de l'entreprise.injecter.le spi.L'Extension.
• Il a un constructeur approprié -, soit:
• la classe dispose d'un constructeur sans paramètres, ou
• la classe déclare un constructeur annotée @Inject.