Acabo de comenzar a leer Core JavaServer Faces, 3rd Ed. y dicen esto (énfasis mío):

Es un accidente histórico que haya dos mecanismos separados, beans CDI y beans administrados JSF, para beans que se pueden usar en páginas JSF. Le sugerimos que utilice beans CDI a menos que su aplicación deba funcionar en un corredor de servlet simple como Tomcat.

¿Por qué? No proporcionan ninguna justificación. He estado usando @ManagedBeanpara todos los beans en una aplicación prototipo que se ejecuta en GlassFish 3, y realmente no he notado ningún problema con esto. No me importa especialmente migrar de @ManagedBeana @Named, pero quiero saber por qué debería molestarme .

Se prefiere CDI sobre JSF simple porque CDI permite la inyección de dependencias en todo JavaEE. También puede inyectar POJO y dejar que se administren. Con JSF solo puede inyectar un subconjunto de lo que puede con CDI.

Utilice CDI.

Según JSF 2.3, @ManagedBeanestá en desuso . Consulte también el número de especificaciones 1417 . Esto significa que no hay más de una razón para elegir @ManagedBeanmás @Named. Esto se implementó por primera vez en Mojarra 2.3.0 versión beta m06.

Historia

La diferencia principal es que @ManagedBeanestá administrado por el marco JSF y solo está @ManagedPropertydisponible para otros beans administrados por JSF. @Namedes administrado por el servidor de aplicaciones (el contenedor) a través de marco CDI y está vía @Injectdisponible para cualquier tipo de artefacto gestionadas por contenedor como @WebListener, @WebFilter, @WebServlet, @Path, @Stateless, etc, e incluso una JSF @ManagedBean. Desde el otro lado en, @ManagedPropertyno no trabajar dentro de una@Named o de cualquier otro artefacto logrado contenedor. Funciona realmente solo por dentro@ManagedBean .

Otra diferencia es que CDI en realidad inyecta proxies que se delegan en la instancia actual en el alcance de destino por solicitud / hilo (como en la forma en que se inyectan los EJB). Este mecanismo permite inyectar un bean de alcance más estrecho en un bean de alcance más amplio, lo que no es posible con JSF @ManagedProperty. JSF "inyecta" aquí la instancia física directamente al invocar a un establecedor (esa es exactamente la razón por la que se requiere un establecedor, mientras que no se requiere con@Inject ).

Si bien no es directamente una desventaja, hay otras formas, el alcance @ManagedBeanes simplemente limitado. Desde la otra perspectiva, si no desea exponer "demasiado" @Inject, también puede mantener sus beans administrados @ManagedBean. Es como protectedversuspublic . Pero eso realmente no cuenta.

Al menos, en JSF 2.0 / 2.1, la principal desventaja de administrar beans de respaldo JSF por CDI es que no hay un equivalente CDI de @ViewScoped. Se @ConversationScopedacerca, pero aún requiere iniciar y detener manualmente y agrega un cidparámetro de solicitud feo a las URL de resultado. MyFaces CODI lo hace más fácil al unir de forma totalmente transparente JSF javax.faces.bean.ViewScopeda CDI para que pueda hacerlo @Named @ViewScoped, sin embargo, eso agrega un windowIdparámetro de solicitud feo a las URL de resultados, también en la navegación simple de página a página. OmniFaces resuelve todo esto con un verdadero CDI @ViewScopedque realmente vincula el alcance del bean al estado de la vista JSF en lugar de a un parámetro de solicitud arbitrario.

JSF 2.2 (que se publica 3 años después de esta pregunta / respuesta) ofrece una nueva @ViewScopedanotación totalmente compatible con CDI lista para usar en formato javax.faces.view.ViewScoped. JSF 2.2 incluso viene con un CDI solo @FlowScopedque no tiene @ManagedBeanequivalente, lo que empuja a los usuarios de JSF hacia CDI. La expectativa es que @ManagedBeany los amigos quedarán obsoletos según Java EE 8. Si todavía lo está utilizando @ManagedBean, se recomienda encarecidamente que cambie a CDI para estar preparado para futuras rutas de actualización. CDI está disponible en contenedores compatibles con Java EE Web Profile, como WildFly, TomEE y GlassFish. Para Tomcat, debe instalarlo por separado, exactamente como ya lo hizo para JSF. Consulte también ¿Cómo instalar CDI en Tomcat?

Con Java EE 6 y CDI tiene diferentes opciones para Managed Beans

• @javax.faces.bean.ManagedBeanse refiere a JSR 314 y se introdujo con JSF 2.0. El objetivo principal era evitar la configuración en el archivo faces-config.xml para usar el bean dentro de una página JSF.
• @javax.annotation.ManagedBean(“myBean”) está definido por JSR 316. Generaliza los beans administrados JSF para su uso en otros lugares de Java EE
• @javax.inject.Named(“myBean”) son casi iguales que el anterior, excepto que necesita un archivo beans.xml en la carpeta web / WEB-INF para activar CDI.

Estaba usando CDI en GlassFish 3.0.1, pero para que funcionara tuve que importar el marco Seam 3 (Weld). Eso funcionó bastante bien.

En GlassFish 3.1, CDI dejó de funcionar y Seam Weld dejó de funcionar. Abrí un error en esto pero aún no lo he solucionado. Tuve que convertir todo mi código para usar las anotaciones javax.faces. * Pero planeo volver a CDI una vez que lo hagan funcionar.

Estoy de acuerdo en que debe usar CDI, pero un problema que aún no he visto resuelto es qué hacer con la anotación @ViewScoped. Tengo mucho código que depende de eso. No está claro si @ViewScoped funciona si no está usando @ManagedBean con él. Si alguien me puede aclarar esto se lo agradecería.

Una buena razón para cambiarse a CDI: podría tener un recurso de ámbito de sesión común (perfil de usuario, por ejemplo) @Injectintegrado tanto en beans administrados por JSF como en servicios REST (es decir, Jersey / JAX-RS).

Por otro lado, @ViewScopedes una razón convincente para seguir con JSF @ManagedBean, especialmente para cualquier cosa con AJAX significativo. No hay un reemplazo estándar para esto en CDI.

Parece que puede tener algún soporte para una @ViewScopedanotación similar a la de los beans CDI, pero no he jugado con ella personalmente.

http://seamframework.org/Seam3/FacesModule