Differenza tra Mojarra e MyFaces

https://stackoverflow.com/questions/4530746

13-10-2019
|

Domanda

Sto iniziando a JSF2.0 Ho usato un tutorial come riferimento, ma ho la seguente domanda:

Il tutorial usato 2 librerie solo:. jsf-api.jar, jsf-impl.jar (ma aveva anche JSTL) da Mojarra Progetto

Ho cercato per scaricare anche loro, ma sembra che il sito non è raggiungibile. Così ho usato Apache MyFaces ma per eseguire l'esempio ho dovuto aggiungere 8 vasetti (commons-*, myfaces-*).
Perché ho bisogno di più vasi se uso MyFaces? Dovrei preferire Mojarra come più leggero? Anche la pagina di download è infatti JSF Mojarra ?

Grazie

Soluzione

Perché ho bisogno di più vasi se uso MyFaces?

Perché quelle dipendenze commons-* non vengono raggruppati in MyFaces. D'altra parte, se si sta utilizzando altre librerie da Apache.org che utilizzano anche quelle dipendenze commons-*, quindi in ultima analisi, si finisce con le librerie di dimensioni più piccole totale.

Notato dovrebbe essere che dal Mojarra 2.1.6 un javax.faces.jar formato di file singolo JAR è disponibile.

dovrebbe preferisco Mojarra come più leggero

Questo è un non-argomento. Si dovrebbe guardare a come robusto e ben mantenuto l'implementazione JSF è.

Il nonno di Mojarra, Sun JSF RI 1.0, e le prime versioni di RI 1.1 sono stati ingombra da bug fastidiosi. In quel momento (circa 2004-2006), MyFaces è stato sicuramente l'alternativa più stabile.

Dal 1.1_02 e 1.2_02 intorno all'inizio del 2006 il nuovo team di sviluppo Sun / Oracle JSF ha fatto grande lavoro. Non solo con bugfixing, ma anche con miglioramenti delle prestazioni. Circa a metà della durata Mojarra 1.2 (circa 2007-2009), Mojarra è stata la scelta migliore rispetto MyFaces.

Dal JSF 2.0, che è venuto con la nuova gestione stato di risparmio parziale, MyFaces era prestazioni saggia la scelta migliore a causa di un approccio diverso e molto più efficiente di calcolo delta dello Stato, in particolare quando si utilizzano alberi di grandi dimensioni dei componenti. Mojarra raggiunto solo a partire dalla versione 2.1.22 . Durante la 2.0 / 2.1 timeline, Mojarra ha avuto problemi seri con solo <ui:repeat> in composizioni complesse / nested (AO rotto risparmio stato, elaborazione solo ultima forma iterata, <f:ajax> fallito, ecc) e con implementazione portata del flash (implementazione iniziale era totalmente non a prova di proiettile). MyFaces avevano anche una propria serie di bug, ma erano gestibili.

In questo momento, con JSF 2.2, non si può davvero dire in anticipo quale è meglio. Bugs spesso espongono solo più tardi e la robustezza possono essere valutati solo durante il periodo successivo. Basta scegliere qualunque applicazione si "sente" è il migliore. Navigare fra i propri rapporti di emissione ( MyFaces e Mojarra ) per conoscere le problematiche precedentemente fissati e le questioni aperte. Se si verifica un errore specifico, provare con entrambe le implementazioni di escludere l'uno e gli altri. Rapporto, se necessario, per mantenere la qualità complessiva delle due implementazioni alta.

Anche la pagina di download è infatti JSF Mojarra ?

La loro home page è stato spostato intorno più volte. Attualmente (settembre 2017) è situato a https://javaserverfaces.github.io Potete trovare le librerie di org.glassfish:javax.faces in Maven centrale troppo. È possibile trovare il codice sorgente in javaserverfaces/mojarra progetto in GitHub . Potete trovare le istruzioni di installazione nella README.md laggiù.

Vedi anche:

Altri suggerimenti

La risposta arriva dal mio 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

UPDATE luglio 2013 : Vedere la serie di articoli e l'aggiornamento per il 2013 a JSFCentral:

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

A prima vista, entrambe le implementazioni JSF (MyFaces e Mojarra) fanno lo stesso, perché si basano sullo stesso standard. Il fatto che si può passare da un'applicazione ad altri è un fatto della qualità del JSF specifica standard.

Ma sul fondo c'è un sacco di motivi per cui MyFaces Nucleo 2.x è meglio di Mojarra. Nota Sono un committer di progetto di MyFaces, quindi ti darò qui solo il mio punto di vista:

Un sacco di problemi è stato risolto. Solo in 2.0.x ramo 2.0.0-alpha per 2.0.7 è stato chiuso 835 problemi. Questo dà una misura "grezza" di quanti contributi e le risposte sono state fornite dalla comunità nel tempo. Questo è il numero di problemi chiusi su tempo: 2.0.0-alpha: 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

Aggiornamento Maggio 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

Comunità oltre il codice: MyFaces conta di comunità con un sacco di gente con una conoscenza eccezionale su JSF. Iscriviti alla mailing list degli utenti e dev sono il modo migliore per sapere cosa sta succedendo, ricevere feedback e conoscere altre persone interessate a JSF. Vedi Mailing List
Apache è ben noto a prendere tutto da Sun / Oracle e renderlo migliore. In questo caso, MyFaces Core ha alcune ottimizzazioni fresco oltre il risparmio dello Stato parziale, componenti in composito e molto altro ancora!.
MyFaces Core è OSGi amichevole. Esso fornisce alcune interfacce SPI a che fare con configurazioni speciali, quando avete bisogno di un maggiore controllo sul classloading.
MyFaces Core ha una migliore compatibilità con facelets 1.1.x. !. Basta impostare org.apache.myfaces.REFRESH_TRANSIENT_BUILD_ON_PSS web config param al vero, e una speciale modalità verrà attivata. No c: se tags oc: forEach o ui: comprendono più ripartiti !. UPDATE maggio 2012 un algoritmo migliorato è stato fatto all'interno MyFaces Nucleo che riducono la dimensione dello Stato, anche in parti quando facelets viene utilizzato per aggiornare l'albero dei componenti in modo dinamico. Questo parametro non è più necessario.
MyFaces ha altri progetti (Trinidad, Tobago, Tomahawk, ExtVal, CODI, Orchestra, PortletBridge RI, ....) che aiuta il codice mastio tune up, perché tutti quei progetti di prova contro MyFaces core, e se non ci è un bug, viene gestito in modo più rapido.
È possibile checkout usando svn e costruire facilmente qualsiasi MyFaces progetto perché tutti loro Maven based e la maggior parte degli IDE fornisce Maven supporto.
Mojarra, al momento attuale (JUN 2011) ha alcuni bug fastidiosi legati al risparmio dello Stato, che MyFaces non ha in quanto la sua applicazione è completamente diverso. Infatti, risparmiando MyFaces parziale stato offerte algoritmo migliore compatibilità con risparmio JSF 1.2 stato che Mojarra. Ma ragazzi nota Mojarra stanno lavorando su questo, ma correzione che li porterà mesi, addirittura anni.
L'innovazione avviene su MyFaces.

UPDATE maggio 2012

Vedere questo articolo 10 motivi per cui scegliere MyFaces Core come JSF implementazione per noib applicazioni

Per i ragazzi che vogliono vedere un confronto delle prestazioni betwen MyFaces, Mojarra e Wicket sguardo JSF comprensione 2 e Wicket: Confronto rendimento

UPDATE luglio 2013

Il confronto è stato esteso ad altri framework come Spring MVC, Tapestry, Grails 2 e Wicket. Si veda l'articolo a JSFCentral: Aggiornamento luglio 2013 a JSFCentral

Direi che non ha molta importanza.

Recentemente ho iniziato un progetto JSF 2.0 utilizzando MyFaces e primefaces. La scorsa settimana, per indagare su un bug, ho cercato di eseguire sul Mojarra. Tutto ha preso stava scambiando le JAR e rimozione di voci MyFaces-specifici in web.xml - e tutto ha funzionato senza problemi. Certo questo era un prototipo che non utilizza tutte le funzionalità JSF, ma sono stato impressionato da questa dimostrazione di compatibilità tramite la conformità agli standard.

Perché ho bisogno di più vasi se uso MyFaces?

MyFaces-impl e MyFaces-API JAR sono l'equivalente di JSF-impl di Mojarra e JSF-api.
MyFaces-bundle contiene entrambi questi per comodità, è necessario questo o gli altri due, non tutti e tre.
commons- * sono le librerie che contengono utili funzionalità di base per trattare con le collezioni, i fagioli Java, ecc che si avrebbe altrimenti reimplementare (probabilmente più lento e con più bug). Molti altri progetti utilizzano questi pure.

Io generalmente bastone con l'attuazione Mojarra a meno che non ci sia qualche motivo per andare con qualcos'altro. Io uso Netbeans, quindi è più facile da usare la messa a punto del progetto di "default", che utilizza Mojarra esecuzione in GlassFish.

Ultimo stavo usando MyFaces, era perché stavo pensando di usare Tomahawk e sembrava ragionevole utilizzare l'implementazione JSF dalla stessa fonte. Comunque ho passato a primefaces invece e che funziona bene sotto Mojarra.

In questo momento sembra che ci sia un sacco di sviluppo in corso con JSF-2.0 librerie di componenti provenienti on-line. Quindi, si dovrebbe imparare ed essere in grado di passare tra le implementazioni JSF nel caso in cui qualcosa va storto.

I MyFaces ragione ha più vasi in esso è che ha più funzionalità di un semplice l'implementazione di riferimento.

che IDE si sta utilizzando? se si utilizza Eclipse, allora verrà scaricato vasi durante la creazione del progetto JSF 2.0. Controllare questo http://www.icesoft.org/training/icefaces-self -serve-training.jsf

Non non c'è molta differenza tra il mojarra e MyFaces. È possibile verificare che uno è più versione stabile. Come ha detto Balusc, MyFaces è la versione stabile più (nel 2005-2006). Inoltre, molte persone hanno iniziato ad usare il Mojarra dopo 2.0 perché è diventato stabile rispetto ai MyFaces

ho avuto seri problemi con mojarra (2.2.8), i comportamenti strani come i metodi ajax solo in esecuzione dopo la seconda interazione con l'utente a causa di aggiornamenti di forma precedenti. Tutto andato con MyFaces.

Autorizzato sotto: CC-BY-SA insieme a attribuzione

Non affiliato a StackOverflow