Diferencia entre Mojarra y MyFaces

Estoy comenzando con JSF2.0. Utilicé un tutorial como referencia, pero tengo la siguiente pregunta:

El tutorial usó solo 2 libs: jsf-api.jar , jsf-impl.jar (pero también tenía JSTL) del Proyecto Mojarra.

Traté de descargarlos también pero parece que el sitio no es alcanzable. Así que utilicé Apache MyFaces, pero para ejecutar el ejemplo tuve que agregar 8 jarras ( commons-* , myfaces-* ).
¿Por qué necesito más jarras si uso MyFaces? ¿Debo preferir Mojarra como más ligero? También la página de descarga es de hecho JSF Mojarra ?

Gracias

¿Por qué necesito más jarras si uso MyFaces?

Porque esas dependencias commons-* no están incluidas en MyFaces. Por otro lado, si está utilizando otras bibliotecas de Apache.org que también usan esas dependencias commons-* , finalmente terminará con bibliotecas de tamaño total más pequeñas.

Notado debe ser que desde Mojarra 2.1.6 está disponible un formato de archivo JAR único javax.faces.jar .


¿Debo preferir Mojarra como encendedor?

Esto no es un argumento Debería ver qué tan robusta y bien mantenida es la implementación de JSF.

El abuelo de Mojarra, Sun JSF RI 1.0 y las primeras versiones de RI 1.1 estaban llenas de errores desagradables. En ese momento (alrededor de 2004-2006), MyFaces fue definitivamente la alternativa más estable.

Desde el 1.1_02 y el 1.2_02 a principios de 2006, el nuevo equipo de desarrollo Sun / Oracle JSF hizo un gran trabajo. No solo con corrección de errores, sino también con mejoras de rendimiento. Aproximadamente a la mitad de la vida de Mojarra 1.2 (alrededor de 2007-2009), Mojarra fue la mejor opción que MyFaces.

Desde JSF 2.0, que venía con una nueva administración parcial de ahorro de estado, MyFaces fue la mejor opción en términos de rendimiento debido a un enfoque diferente y mucho más eficiente para calcular los deltas de estado, particularmente cuando se usan árboles de componentes grandes. Mojarra atrapado solo desde la versión 2.1.22 . Durante la línea de tiempo 2.0 / 2.1, Mojarra solo tuvo problemas serios con en composiciones complejas / anidadas (un ahorro de estado interrumpido, procesando solo la última forma iterada, fallado , etc.) y con implementación de scope de flash ( la implementación inicial no fue totalmente a prueba de balas). MyFaces también tenía su propio conjunto de errores, pero eran manejables.

En este momento, con JSF 2.2, uno realmente no puede decir de antemano cuál es mejor. Los errores a menudo se exponen solo más tarde y la solidez solo se puede evaluar durante el período posterior. Solo elige la implementación que “sientas” es la mejor. Examine sus informes de problemas ( MyFaces y Mojarra ) para obtener información sobre los problemas corregidos previamente y los problemas actualmente abiertos. Si encuentra un error específico, intente con ambas implementaciones para excluir el uno y el otro. Informe si es necesario para mantener alta la calidad general de ambas implementaciones.


También la página de descarga es de hecho JSF Mojarra ?

Su página de inicio ha sido movida varias veces. Actualmente (Sep 2017) se encuentra en https://javaserverfaces.github.io. También puede encontrar las bibliotecas en org.glassfish:javax.faces en Maven Central . Puede encontrar el código fuente en el proyecto javaserverfaces/mojarra en GitHub . Puede encontrar las instrucciones de instalación en el README.md allí.


Ver también:

  • ¿Cuáles son las principales desventajas de Java Server Faces 2.0?
  • Cuál es la diferencia entre las implementaciones de JSF y las bibliotecas de componentes

La respuesta viene de mi blog:

http://lu4242.blogspot.com/2011/06/10-reason-why-choose-myfaces-core-as.html http://lu4242.blogspot.com/2012/05/understandingjsf-2-and-wicket .html

ACTUALIZACIÓN EN JULIO DE 2013 : Consulte la serie de artículos y la actualización de 2013 en JSFCentral:

http://www.jsfcentral.com/articles/understanding_jsf_performance_3.html


A primera vista, ambas implementaciones JSF (MyFaces y Mojarra) hacen lo mismo, porque están basadas en el mismo estándar. El hecho de que pueda cambiar de una implementación a otra es un hecho de la calidad de la especificación estándar de JSF.

Pero en la parte inferior hay muchas razones por las que MyFaces Core 2.x es mejor que Mojarra. Tenga en cuenta que soy un committer del proyecto MyFaces, así que le doy aquí solo mi punto de vista:

  • Se han solucionado muchos problemas. Solo en la twig 2.0.x de 2.0.0-alpha a 2.0.7 se han cerrado 835 problemas. Esto proporciona una medida “cruda” de la cantidad de contribuciones y comentarios que la comunidad ha proporcionado a lo largo del tiempo. Este es el número de problemas cerrados en el tiempo: 2.0.0-alfa: 274, 2.0.0-beta: 58, 2.0.0-beta-2: 41, 2.0.0-beta-3: 39, 2.0.0 : 51, 2.0.1: 148, 2.0.2: 77, 2.0.3: 63, 2.0.4: 23, 2.0.5: 27, 2.0.6: 29, 2.0.7: 5.

ACTUALIZACIÓN MAYO DE 2012: 2.1.0: 47, 2.1.1: 6, 2.1.2: 84, 2.1.3: 9, 2.1.4: 74, 2.1.5: 7, 2.1.6: 35, 2.1.7: 52

  • Comunidad con código: la comunidad MyFaces cuenta con mucha gente con un conocimiento excelente sobre JSF. Suscribirse al usuario y la lista de distribución de dev son la mejor manera de saber lo que está pasando, recibir comentarios y conocer a otras personas interesadas en JSF. Ver listas de correo de MyFaces

  • Apache es muy conocido por tomar todo de Sun / Oracle y hacerlo mejor. En este caso, MyFaces Core tiene algunas optimizaciones geniales sobre el ahorro de estado parcial, componentes compuestos y mucho más.

  • MyFaces Core es compatible con OSGi. Proporciona algunas interfaces SPI para tratar configuraciones especiales, cuando necesita más control sobre la carga de clases.

  • MyFaces Core tiene una mejor compatibilidad con facelets 1.1.x !. Simplemente configure org.apache.myfaces.REFRESH_TRANSIENT_BUILD_ON_PSS web config param en true, y se activará un modo especial. No c: if tags o c: forEach o ui: ¡incluyen roto más !. ACTUALIZACIÓN MAYO DE 2012 Se realizó un algoritmo mejorado dentro de MyFaces Core que reduce el tamaño del estado incluso en partes cuando se usa facelets para actualizar dinámicamente el árbol de componentes. Este parámetro ya no es necesario.

  • MyFaces tiene otros proyectos (Trinidad, Tobago, Tomahawk, ExtVal, CODI, Orchestra, PortletBridge RI, ….) que ayudan a mantener el ajuste del código, porque todos esos proyectos prueban contra MyFaces Core, y si hay un error, es manejado más rápido.

  • Puede realizar el pago usando svn y comstackr fácilmente cualquier proyecto MyFaces, ya que todos ellos basados ​​en el administrador y la mayoría de los IDE proporcionan soporte técnico.

  • Mojarra en este momento (JUN 2011) tiene algunos errores desagradables relacionados con el ahorro de estado, que MyFaces no tiene porque su implementación es completamente diferente. De hecho, el algoritmo de ahorro de estado parcial MyFaces ofrece una mejor compatibilidad con el ahorro de estado JSF 1.2 que Mojarra. Pero tenga en cuenta que los muchachos de Mojarra están trabajando en eso, pero eso los llevará meses, incluso años.

  • La innovación ocurre en MyFaces.

ACTUALIZACIÓN MAYO 2012

Consulte este artículo 10 por qué elegir MyFaces Core como implementación de JSF para aplicaciones web

Para los tipos que quieren ver una comparación de rendimiento entre MyFaces, Mojarra y Wicket, mire Comprensión de JSF 2 y Wicket: Comparación de rendimiento

ACTUALIZACIÓN JULIO 2013

La comparación se amplió para incluir otros marcos como Spring MVC, Tapestry, Grails 2 y Wicket. Vea el artículo en JSFCentral: Actualice JUL 2013 en JSFCentral

Yo diría que realmente no importa.

Recientemente comencé un proyecto JSF 2.0 usando Myfaces and Primefaces. La semana pasada, para investigar un error, intenté ejecutarlo en Mojarra. Todo lo que se necesitó fue intercambiar los JAR y eliminar las entradas específicas de Myfaces en web.xml, y todo funcionó sin ningún problema. Es cierto que este fue un prototipo que no utiliza toda la funcionalidad JSF, pero quedé bastante impresionado por esta demostración de compatibilidad a través del cumplimiento de estándares.

¿Por qué necesito más jarras si uso MyFaces?

  • Los JAR myfaces-impl y myfaces-api son el equivalente de jsf-impl y jsf-api de Mojarra.
  • myfaces-bundle contiene ambos para su conveniencia, necesita este u otros dos, no los tres.
  • commons- * son bibliotecas que contienen funcionalidades básicas útiles para tratar con colecciones, beans Java, etc. que de otro modo tendrían que volverse a implementar (probablemente más lentas y con más errores). Muchos otros proyectos usan esto también.

En general me quedo con la implementación de Mojarra a menos que haya alguna razón para ir con otra cosa. Yo uso Netbeans, así que es más fácil usar la configuración de proyecto “predeterminada” que usa Mojarra corriendo bajo GlassFish.

La última vez que usé MyFaces, fue porque estaba pensando en usar Tomahawk y me pareció razonable usar la implementación de JSF de la misma fuente. Sin embargo, he cambiado a Primefaces y eso funciona bien bajo Mojarra.

En este momento parece que se está desarrollando mucho con las bibliotecas de componentes JSF-2.0 en línea. Por lo tanto, debe aprender y ser capaz de cambiar entre las implementaciones de JSF en caso de que algo salga mal.

La razón por la que MyFaces tiene más flasks es que tiene más funcionalidad que solo la implementación de referencia.

qué IDE estás usando? si está utilizando eclipse, descargará jarrones mientras crea el proyecto jsf 2.0. Mira esto http://www.icesoft.org/training/icefaces-self-serve-training.jsf

No hay mucha diferencia entre mojarra y MyFaces. Puede verificar cuál es la versión más estable. Como dijo Balusc, MyFaces es la versión más estable (en 2005-2006). Además, muchas personas comenzaron a usar Mojarra después de 2.0 porque se ha estabilizado en comparación con los aspectos secundarios

Estaba teniendo dolores de cabeza graves con mojarra (2.2.8), comportamientos extraños, como los métodos ajax, que solo se ejecutan después de la segunda interacción del usuario debido a actualizaciones de formularios anteriores. Todo desapareció con MyFaces.