Diferencia entre Mojarra y MyFaces

https://stackoverflow.com/questions/4530746

13-10-2019
|

Pregunta

Estoy empezando en JSF2.0 que utiliza un tutorial como referencia, pero tengo la siguiente pregunta:

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

He intentado dowload ellos también, pero parece que el sitio no es accesible. Por lo que utiliza Apache MyFaces sino para ejecutar el ejemplo he tenido que añadir 8 frascos (commons-*, myfaces-*).
¿Por qué necesito más frascos si uso MyFaces? Debería preferir Mojarra tan ligero? También la página de descarga es de hecho JSF Mojarra ?

Gracias

Solución

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

Debido a esas dependencias commons-* no están agrupados en MyFaces. Por otro lado, si estás usando otras bibliotecas de Apache.org que también utilizan esas dependencias commons-*, a continuación, en última instancia, termina con bibliotecas tamaño total más pequeñas.

Destaca debe ser que ya Mojarra 2.1.6 javax.faces.jar un solo formato de archivo JAR está disponible.

¿Debo prefieren Mojarra como más ligero

Esto es un no-argumento. Usted debe buscar la forma robusta y bien mantenido la implementación JSF es.

El abuelo de la Mojarra, Sun JSF 1.0 RI, y las primeras versiones de RI 1.1 se amontonaban por los insectos desagradables. En ese momento (alrededor de 2004-2006), MyFaces fue sin duda la alternativa más estable.

Desde 1.1_02 y 1.2_02 torno a principios de 2006, el nuevo equipo de desarrollo de Sun / Oracle JSF hizo un gran trabajo. No sólo con bugfixing, sino también con mejoras de rendimiento. Hacia la mitad de la vida útil Mojarra 1.2 (alrededor de 2007-2009), Mojarra fue la mejor elección que MyFaces.

Desde JSF 2.0, que llegó con una nueva gestión parcial del estado de ahorro, MyFaces era refiere a rendimiento la mejor opción debido a un enfoque diferente y mucho más eficiente de calcular los deltas de estado, sobre todo cuando se utilizan grandes árboles de componentes. Mojarra alcanzó sólo a partir de la versión 2.1.22 . Durante la línea de tiempo 2.0 / 2.1, Mojarra tenía problemas graves con solamente <ui:repeat> en composiciones complejas / anidada (AO roto estado de ahorro, el procesamiento de solamente última forma iterativa, <f:ajax> fallado, etc) y con flash de aplicación ámbito de aplicación (aplicación inicial era totalmente no es a prueba de balas). MyFaces también tenían su propio conjunto de errores, pero eran manejables.

En este momento, con JSF 2.2, no se puede realmente decir de antemano cuál es mejor. Insectos a menudo exponen sólo más tarde y robustez sólo pueden ser evaluados durante las consecuencias. Sólo tiene que elegir lo que la aplicación "sensación" es el mejor. Navegar a través de sus informes de emisión ( MyFaces y Mojarra ) para aprender sobre los temas previamente fijados y las cuestiones abiertas en ese momento. Si se encuentra con un error específico, tratar con las dos implementaciones para excluir a uno y otro. Informe si es necesario para mantener la calidad general de las implementaciones de ambos alta.

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

Su página de inicio se ha movido en torno a varias veces. Actualmente (sep 2017) se encuentra en https://javaserverfaces.github.io puede encontrar en las bibliotecas org.glassfish:javax.faces en Maven central también. Puede encontrar el código fuente en javaserverfaces/mojarra en GitHub . Puede encontrar las instrucciones de instalación en la README.md por allí.

Ver también:

Otros consejos

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 de julio de 2013 : Ver la serie de artículos y la actualización para 2013 en JSFCentral:

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

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

Pero en el fondo hay una gran cantidad de razones por las MyFaces Core 2.x es mejor que Mojarra. Tenga en cuenta que soy un confirmador del proyecto MyFaces, por lo que te voy a dar aquí sólo mi punto de vista:

Una gran cantidad de problemas se ha solucionado. Sólo 2.0.x rama de 2.0.0 a 2.0.7-alfa se ha cerrado 835 temas. Esto da una medida "en bruto" de la cantidad de contribuciones y retroalimentación ha sido proporcionada por la comunidad a través del tiempo. Se trata de los números para cuestiones cerrados sobre 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 de 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 más de código: MyFaces recuento de la comunidad con una gran cantidad de gente con conocimientos pendiente en JSF. Suscríbete a la lista de correo del usuario y dev son la mejor manera de saber lo que está pasando, recibir retroalimentación y conocer a otras personas interesadas en JSF. Ver Listas de correo
Apache es bien sabido tomar todo de Sun / Oracle y hacerlo mejor. En este caso, MyFaces Core tiene algunas optimizaciones fría sobre ahorro estado parcial, componentes compuestos y mucho más!.
MyFaces Core es OSGi amigable. Proporciona algunas interfaces SPI para hacer frente a las configuraciones especiales, cuando se necesita más control sobre la carga de clase.
MyFaces núcleo tiene una mejor compatibilidad con facelets 1.1.x !. Sólo hay que establecer org.apache.myfaces.REFRESH_TRANSIENT_BUILD_ON_PSS parámetro de configuración web de verdad, y se activará un modo especial. No c: si las etiquetas oc: forEach o ui: include rompen más !. actualización de mayo de 2012 Un algoritmo mejorado se realiza en el interior MyFaces Core que reducen el tamaño del Estado, incluso en partes cuando facelets se utiliza para actualizar el árbol de componentes de forma dinámica. Este parámetro ya no es necesario.
MyFaces tiene otros proyectos (Trinidad, Tobago, Tomahawk, ExtVal, CODI, orquesta, PortletBridge RI, ....) que ayuda a mantener código de puesta a punto, ya que todas las pruebas de esos proyectos contra MyFaces Core, y si hay es un error, que se maneja con mayor rapidez.
Puedes retirar usando SVN y construir fácilmente cualquier MyFaces proyectan, porque todos ellos basados ??Maven y la mayoría de los IDE proporciona apoyo Maven.
Mojarra en el momento actual (JUN 2011) tiene algunos errores desagradables relacionados con el ahorro estatal, que MyFaces no tiene porque su aplicación es completamente diferente. De hecho, MyFaces estado parcial ofertas para ahorrar algoritmo mejor compatibilidad con JSF 1.2 estado de ahorro de Mojarra. Pero tenga en cuenta Mojarra chicos están trabajando en eso, pero fijo que les llevará meses, incluso años.
La innovación se produce en MyFaces.

actualización de mayo de 2012

Ver este artículo 10 por lo que elegir MyFaces Core como JSF aplicación para queb aplicaciones

Para los chicos que quieren ver una comparación de rendimiento Transcurrirá MyFaces, Mojarra y el aspecto Wicket comprensión JSF 2 y wicket: Comparación de rendimiento

actualización de julio de 2013

La comparación se amplió para incluir otros marcos como Spring MVC, tapicería, Grails 2 y wicket. Ver el artículo en JSFCentral: Actualización-JUL-2013 en JSFCentral

Yo diría que realmente no importa.

Hace poco comenzó un proyecto JSF 2.0 utilizando MyFaces y Primefaces. La semana pasada, para investigar un error, traté de ejecutarlo en Mojarra. Todo lo que tomó intercambiaba los frascos y eliminación de entradas MyFaces-específicas en web.xml - y todo funcionaba sin ningún problema. Es cierto que se trataba de un prototipo que no utiliza toda la funcionalidad JSF, pero yo estaba muy impresionado por esta demostración de la compatibilidad a través de cumplimiento de las normas.

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

MyFaces-impl y MyFaces-API JAR son el equivalente de JSF-impl de Mojarra y JSF-api.
MyFaces-paquete contiene ambos por conveniencia, necesita esto o los otros dos, no los tres.
commons- * son bibliotecas que contienen funcionalidad básica útiles para tratar con colecciones, Java Beans, etc. que uno de otra manera tendrían que volver a implementar (probablemente más lento y con más errores). Muchos otros proyectos utilizan estos también.

Yo por lo general a seguir con la implementación Mojarra menos que haya alguna razón para seguir con otra cosa. Yo uso Netbeans, por lo que es más fácil de utilizar la configuración del proyecto "por defecto", que utiliza Mojarra ejecuta en GlassFish.

La última vez que estaba usando MyFaces, que era porque yo estaba pensando en usar Tomahawk y parecía razonable utilizar la implementación JSF de la misma fuente. Sin embargo, he cambiado a Primefaces lugar y que funciona bien bajo Mojarra.

En este momento parece que hay un montón de desarrollo pasando con JSF-2.0 bibliotecas de componentes que entrarán en funcionamiento. Por lo que debe aprender y ser capaz de cambiar entre las implementaciones JSF en caso de que algo va mal.

La razón MyFaces tiene más frascos en ella es que tiene más funcionalidad que sólo la implementación de referencia.

IDE que está utilizando? si está utilizando Eclipse entonces se descarga frascos mientras que la creación de proyectos JSF 2.0. Marque esta http://www.icesoft.org/training/icefaces-self -Serve-training.jsf

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

I estaba teniendo graves dolores de cabeza con mojarra (2.2.8), los comportamientos extraños tales como los métodos ajax solamente se ejecutan después de la segunda interacción del usuario debido a las actualizaciones forma anterior. Todo se ha ido con MyFaces.

Licenciado bajo: CC-BY-SA con atribución

No afiliado a StackOverflow