jsf - que - ¿Están @ManagedBeans obsoletos en JavaEE6 debido a @Named en CDI/Weld?

jboss wikipedia (4)

Debido a CDI (y su implementación Weld), cada POJO en JEE6 se puede anotar con @Named , lo que hace que POJO sea accesible para la vista.

¿Eso significa que los ManagedBeans ahora están completamente obsoletos? ¿O me perdí algo donde @ManagedBean todavía tiene sentido?

CDI no tiene alcance de vista, porque no tiene la noción de una vista , por lo que si necesita ese alcance, CDI en su forma pura no puede hacerlo. El alcance de la vista básicamente significa que el alcance de la solicitud + está preparado para AJAX . No es una vista JSF, como una página llamada xyz.xhtml , aunque ve JSF <f:viewParam> y los "me gusta". Un caso de uso frecuente con beans con vista es cómo obtener los parámetros GET en un bean de ese tipo . Lee esto también

Tenga en cuenta que CDI vive más bien en la capa EJB / servicio que en la capa JSF / presentación. Este blog tiene una buena visión general.

Como tal, @ManagedBean no puede ser reemplazado completamente por CDI, nuevamente si está usando beans @ViewScoped , al menos no sin extender el CDI o usar el módulo Seam 3 Faces . El uso de beans de ámbito de vista casi siempre va a suceder cuando se utilizan kits de herramientas GUI basadas en AJAXed JSF 2 como RichFaces, PrimeFaces, IceFaces, etc.

Mezclar anotaciones de los paquetes erróneos de Java EE 6 puede ocasionarle problemas de forma inesperada, nuevamente al usar RichFaces o una API similar:

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

son para componentes utilizados únicamente en la capa de presentación, aquí por RichFaces, PrimeFaces, etc. Algunos componentes ricos parecen tener problemas con los beans auxiliares anotados por CDI y anotados por JSF . Si obtiene un comportamiento extraño de sus granos (o frijoles que parecen no hacer nada), la causa puede ser una combinación equivocada de anotaciones.

Mezclando JSF y CDI, como

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

es posible y funciona en la mayoría de los casos cuando se hace referencia a páginas JSF; sin embargo, hay algunos problemas / inconvenientes poco conocidos, por ejemplo, cuando se utiliza un alcance JSF que CDI no tiene :

Además, la combinación @Named @ViewScoped no funcionará según lo previsto. El @ViewScoped específico de @ViewScoped funciona en combinación con @ViewScoped específico de JSF solamente. Su @Named específico de CDI se comportará como @RequestScoped esta manera. Utilice @ManagedBean lugar de @Named o use CDI-specific @ConversationScoped lugar de @ViewScoped .

Entonces

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

puede usarse para beans CDI referenciados directamente desde sus páginas JSF AFAIK. No he tenido ningún problema con las combinaciones anteriores hasta el momento, por lo que podría considerar @ManagedBean obsoleto aquí.

Lo que queda es la capa de servicio, aquí la mayoría de los beans de servicio EJB transaccionales declarados como

@javax.ejb.*

mayormente @ javax.ejb.Stateless. Incluso puede anotar y usar EJB directamente desde páginas JSF , aunque no estoy seguro de si este diseño es deseable. Para referenciar (inyectar) cualquier componente anotado con @javax.ejb. *, Por ejemplo @Stateless , prefiera @Inject sobre @EJB como se describe aquí . (Probablemente un antepasado de esta respuesta ...)

Finalmente, se puede encontrar una muy buena descripción de las anotaciones de Java EE 6 aquí: http://www.physics.usyd.edu.au/~rennie/javaEEReferenceSheet.html

Nota : la información anterior no es de un experto, sino simplemente mi propia vista desde la perspectiva de los recién llegados sobre este espagueti de anotaciones Java EE 6 ridículamente confuso . Más conocimiento aún no se ha desarrollado. Espero que esta respuesta pueda ser una respuesta general y práctica a esta confusión, a pesar de que ha ido un poco por la borda en el contexto de la pregunta original.

Como acabo de leer en Weld Reference (p. 12), @ManagedBean ahora es superfloo:

Puede declarar explícitamente un bean gestionado anotando la clase de bean @ManagedBean, pero en CDI no es necesario. De acuerdo con la especificación, el contenedor CDI trata cualquier clase que satisfaga las siguientes condiciones como un bean gestionado:
No es una clase interna no estática. Es una clase concreta, o está anotado @Decorator.
No está anotado con una anotación definitoria de componentes EJB ni está declarado como una clase de bean EJB en ejb-jar.xml.
No implementa javax.enterprise.inject.spi.Extension.
Tiene un constructor apropiado, ya sea:
la clase tiene un constructor sin parámetros, o
la clase declara un constructor anotado @Inject.

En resumen, @ManagedBean tiene sentido para las aplicaciones que usan JSF pero no usan JSR 299 (cualquiera que sea el motivo). Debajo de una explicación más larga de Gavin King:

Re: Comparaciones a @ManagedBean anotaciones en JSF2 :
Mientras examina los ejemplos de Weld y la documentación anterior de WebBeans, parece una competencia para las nuevas anotaciones de @ManagedBean JSF 2.0. ¿Hay alguna información sobre cuándo queremos usar una sobre la otra?
Es una buena pregunta, y realmente no estoy totalmente de acuerdo con las respuestas que se han publicado hasta ahora.
La nueva especificación EE Beads gestionados define un modelo de componente base para Java EE, junto con un conjunto muy básico de servicios de contenedor ( @Resource , @PostConstruct , @PreDestroy ).
La idea es que otras especificaciones (comenzando con EJB, CDI, JSF y la nueva especificación de Java Interceptors) se basen en este modelo de componente básico y en servicios adicionales de capa, por ejemplo, gestión de transacciones, inyección de dependencia segura, interceptores. Por lo tanto, en este nivel, los frijoles administrados, el CDI, los interceptores y las especificaciones EJB funcionan mano a mano y son altamente complementarios.
Ahora, la especificación Managed Beans es bastante abierta con respecto a la identificación exacta de qué clases son beans gestionados. Proporciona la anotación @ManagedBean como un mecanismo, pero también permite que otras especificaciones definan diferentes mecanismos. Así por ejemplo:
La especificación EJB dice que una clase que obedece a ciertas restricciones de programación con una anotación @Stateless o @Stateful desplegada en un jar EJB es un bean administrado.
La especificación CDI dice que cualquier clase con un constructor apropiado desplegado en un "archivo de despliegue de beans" es un bean administrado.
Dado que EJB y CDI proporcionan maneras posiblemente más convenientes de identificar un bean administrado, es posible que se pregunte exactamente para qué se necesita @ManagedBean . La respuesta, como lo alude Dan, es que si tienes CDI disponible en tu entorno (por ejemplo, si estás utilizando EE6), entonces @ManagedBean simplemente no es realmente necesario. @ManagedBean está realmente disponible para personas que usan JSF2 sin CDI .
OTOH, si anotas un bean @ManagedBean , y tienes CDI en tu entorno, aún puedes usar CDI para inyectar cosas en tu bean. Es solo que la anotación @ManagedBean no es necesaria en este caso.
En resumen, si tiene CDI disponible, proporciona un modelo de programación muy superior al modelo @ManagedBean / @ManagedProperty que JSF2 hereda de JSF1 . De hecho, es tan superior que el perfil web de EE 6 no requiere soporte para @ManagedProperty etc. La idea es que simplemente debe usar CDI.

Tienes una opción. Utilice el @ManagedBean de JSF2 para enlazar beans en sus formularios, o use la anotación @Named de CDI. Si planea solo hacer JSF, puede apegarse a @ManagedBean, pero si desea integrarse con EJB, o hacer uso de @ConversationScoped de CDI, siga la ruta CDI.

Personalmente, creo que la próxima versión de JSF debería desaprobar el @ManagedBean y estandarizar en CDI. La dualidad es confusa para los recién llegados.