Sont @ManagedBeans obsolètes dans JavaEE6 en raison de @Named en CDI / Weld?

Question

En raison du CDI (et sa mise en œuvre de soudure), tous les POJO en JEE6 peut être annotées avec @Named, ce qui rend le POJO accessible à la vue.

Est-ce que cela veut dire que ManagedBeans sont complètement obsolète? Ou ai-je raté quelque chose où @ManagedBean encore un sens?

Answer 1

En bref, @ManagedBean est logique pour les applications qui utilisent JSF mais n'utilisent pas JSR 299 (quelle que soit la raison en est). Ci-dessous une explication plus de Gavin King:

  

Re: Les comparaisons avec les annotations @ManagedBean dans JSF2 :

     

    

Tout en regardant à travers les exemples de soudure, et les anciens WebBeans     la documentation, il ressemble à un     concurrent du nouveau JSF @ManagedBean     2.0 annotations. Y at-il des informations sur le moment où nous voudrions utiliser     un sur l'autre?

  

     

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

     

La nouvelle spécification Beans Managed EE   définit un modèle de composant de base pour   Java EE, avec un très basique   un ensemble de services de conteneurs (@Resource,   @PostConstruct, @PreDestroy).

     

L'idée est que d'autres spécifications   (En commençant par EJB, CDI, JSF et   nouvelle spécification Java Interceptor) build sur   ce modèle composant base et la couche   des services supplémentaires, par exemple   la gestion des transactions, typesafe   l'injection de dépendance, les intercepteurs. Donc   à ce niveau, les haricots gérés, CDI,   intercepteurs et les spécifications EJB   toute la main dans la main et le travail sont très   complémentaire.

     

Maintenant, la spécification Beans Managed   est tout à fait ouvert à composition non limitée par rapport à   identifier exactement quelles sont les classes   haricots gérés. Il ne fournit la   annotation @ManagedBean comme une   mécanisme, mais il permet aussi d'autres   spécifications pour définir différentes   mécanismes. Ainsi, par exemple:

     

  

• La spécification EJB dit qu'une classe obéissant à certains programmes   restrictions avec @Stateless ou   annotation @Stateful déployé dans un   jar EJB est un bean géré.

  

• La spécification CDI dit que toute la classe avec un constructeur approprié   déployé dans un « déploiement de haricots   archive » est un bean géré.

  

     

Étant donné que EJB et CDI fournissent   sans doute des moyens plus pratiques pour   identifier un bean géré, vous pouvez   demande précisément ce que @ManagedBean est   nécessaire pour. La réponse, comme allusion à   par Dan, est que si vous avez CDI   disponible dans votre environnement (pour   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 utilisent JSF2   sans CDI .

     

OTOH, si vous annoter un haricot   @ManagedBean, et vous n'avez CDI dans   votre environnement, vous pouvez toujours utiliser   CDI à injecter des choses dans votre haricot.   Il est juste que la @ManagedBean   annotation n'est pas requis dans ce   cas.

     

Pour résumer, si vous avez CDI   à votre disposition, il fournit une far   modèle de programmation supérieure à la   @ManagedBean / modèle de @ManagedProperty   héritant JSF2 de JSF1 . Donc   supérieure, en effet, que la bande EE 6   le profil ne nécessite pas de support pour   @ManagedProperty etc. L'idée étant   que vous devez simplement utiliser CDI à la place.

Answer 2

Vous avez le choix. Soit utiliser le @ManagedBean de JSF2 pour lier les haricots dans vos formes, ou utiliser l'annotation @Named de CDI. Si vous envisagez de ne faire JSF, vous pouvez coller à @ManagedBean, mais si vous souhaitez intégrer avec EJB, ou de faire usage de @ConversationScoped de CDI, puis suivre la voie CDI.

Personnellement, je me sens la prochaine version du JSF devrait désapprouver la @ManagedBean et de normaliser le CDI. La dualité est source de confusion pour les nouveaux arrivants.

Answer 3

CDI n'a pas de portée de vue, car il ne pas la notion d'une vue , donc si vous avez besoin que la portée, le CDI dans sa forme pure ne peut pas le faire. Voir le champ d'application signifie essentiellement demande étendue + AJAX-être prêt . Il de pas une vue JSF, comme une page nommée xyz.xhtml, même si vous voyez JSF <f:viewParam> et les goûts. Un cas d'utilisation fréquente avec des haricots scope vue-est comment obtenir les paramètres GET dans une telle de haricots. Aussi lire .

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

En tant que tel @ManagedBean ne peut pas être entièrement remplacé par CDI, encore une fois si vous utilisez des haricots de @ViewScoped - du moins pas sans extension CDI ou en utilisant le Seam 3 Faces module. L'utilisation des haricots de vue-scope est presque toujours va se passer lors de l'utilisation des boîtes à outils de l'interface graphique à base de 2 AJAXed JSF comme RichFaces, PrimeFaces, Icefaces etc.

annotations Le mélange des mauvaises Java EE 6 paquets peut vous causer des ennuis de façon inattendue, encore une fois lors de l'utilisation RichFaces ou une API similaire:

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

sont utilisés pour les composants uniquement à la couche de présentation, ici par RichFaces, PrimeFaces, etc. Certains composants riches semblent avoir des problèmes avec CDI-annotées et les haricots d'aide JSF-annotés . Si vous obtenez un comportement étrange de vos haricots (ou les haricots qui semblent ne rien faire) le mauvais mélange des annotations pourrait ê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 dans les pages JSF, mais il y a quelques problèmes / inconvénients peu connus, par exemple lorsque utilisant un champ JSF qui ne dispose pas des CDI :

  

De plus, le @Named @ViewScoped combinaison ne fonctionne pas comme prévu. Les travaux de @ViewScoped spécifiques à JSF en combinaison avec @ManagedBean spécifique JSF uniquement. Votre @Named CDI spécifique se comportera comme @RequestScoped cette façon. Soit utiliser @ManagedBean au lieu de @Named ou utiliser @ConversationScoped spécifique au lieu de CDI-@ViewScoped.

Ensuite

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

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

Ce qui reste est la couche de service, ici la plupart des grains de services transactionnels EJB déclarés comme

@javax.ejb.*

la plupart du temps @ javax.ejb.Stateless. Vous pouvez même annoter et à utiliser directement à partir des pages EJBs JSF - bien que je ne suis pas sûr si cette conception est souhaitable. Pour référence (injecter) des composants annotées 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, se trouve une vue d'ensemble très agréable d'annotations Java EE 6 ici: http://www.physics.usyd.edu.au/~rennie/ javaEEReferenceSheet.html

Remarque : les informations ci-dessus ne provient pas d'un expert, mais simplement ma propre version / vue d'un point de vue des nouveaux arrivants sur cette ridiculement confondant Java EE 6 annotations spaghettis . Plus de perspicacité n'a pas encore été mis au point. J'espère que cette réponse peut être une endurent réponse pratique générale, à cette confusion -., Même si elle est allée un peu trop loin dans le contexte de la question initiale

Answer 4

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

  

Vous pouvez explicitement déclarer une gestion   haricot en annotant la classe bean   @ManagedBean, mais en CDI vous n'avez pas   besoin de. Selon le   spécification, le récipient CDI   traite toute classe qui satisfait aux   les conditions suivantes comme géré   haricot:

     

  
• Il est pas une classe interne non statique. Il est une classe de béton, ou est   @Decorator annoté.
  
• Il est pas annotées avec une annotation de composants définissant EJB ou   déclarée comme une classe d'haricot EJB dans   ejb-jar.xml.
  
• Il ne met pas en œuvre javax.enterprise.inject.spi.Extension.
  
• Il a un constructeur-soit approprié:
  
• la classe a un constructeur sans paramètre, ou
  
• la classe déclare un constructeur annotée @Inject.