Differenza tra Mojarra e MyFaces

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

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

Ho provato a scaricarli anche ma sembra che il sito non sia raggiungibile. Quindi ho usato Apache MyFaces ma per eseguire l’esempio ho dovuto aggiungere 8 jars ( commons-* , myfaces-* ).
Perché ho bisogno di più vasetti se utilizzo MyFaces? Dovrei preferire il Mojarra come più leggero? Anche la pagina di download è effettivamente JSF Mojarra ?

Grazie

    Perché ho bisogno di più vasetti se utilizzo MyFaces?

    Perché quelle dipendenze commons-* non sono raggruppate in MyFaces. D’altra parte, se stai usando altre librerie da Apache.org che usano anche queste dipendenze commons-* , allora alla fine commons-* con librerie di dimensioni totali più piccole.

    Si noti che dal mojarra 2.1.6 è disponibile un unico file JAR in formato javax.faces.jar .


    Dovrei preferire il Mojarra come più leggero

    Questo è un non-argomento. Dovresti considerare quanto sia robusta e ben gestita l’implementazione di JSF.

    Il nonno di Mojarra, Sun JSF RI 1.0 e le prime versioni di RI 1.1 erano ingombri di cattivi bug. In quel momento (intorno al 2004-2006), MyFaces era decisamente l’alternativa più stabile.

    Dall’1.1_02 e dall’1.2_02 verso l’inizio del 2006 il nuovo team di sviluppo JSF di Sun / Oracle ha svolto un ottimo lavoro. Non solo con bugfixing, ma anche con miglioramenti delle prestazioni. A circa metà della durata del Mojarra 1.2 (intorno al 2007-2009), Mojarra è stata la scelta migliore rispetto a MyFaces.

    Dal momento che JSF 2.0, che è stato dotato di una nuova gestione parziale del risparmio di stato, MyFaces ha rappresentato per le prestazioni la scelta migliore a causa di un approccio diverso e più efficiente di calcolo dei delta di stato, in particolare quando si utilizzano alberi di componenti di grandi dimensioni. Mojarra si è verificato solo dalla versione 2.1.22 . Durante la timeline 2.0 / 2.1, Mojarra ha avuto solo seri problemi con in composizioni complesse / nidificate (risparmio di stato interrotto, elaborazione dell’ultima forma iterata, errore , ecc.) E implementazione dello scope flash ( l’implementazione iniziale non era totalmente a prova di proiettile). MyFaces aveva anche una serie di bug, ma erano gestibili.

    In questo momento, con JSF 2.2, non si può davvero dire in anticipo quale sia il migliore. Gli insetti spesso vengono esposti solo più tardi e la robustezza può essere valutata solo in seguito. Scegli l’implementazione che “senti” è la migliore. Sfoglia i report dei problemi ( MyFaces e Mojarra ) per conoscere i problemi precedentemente risolti e i problemi attualmente aperti. Se incontri un bug specifico, prova con entrambe le implementazioni per escludere l’uno e l’altro. Segnalare se necessario per mantenere alta la qualità generale di entrambe le implementazioni.


    Anche la pagina di download è effettivamente JSF Mojarra ?

    La loro homepage è stata spostata più volte. Attualmente (settembre 2017) si trova su https://javaserverfaces.github.io Puoi trovare le librerie in org.glassfish:javax.faces in Maven Central . Puoi trovare il codice sorgente nel progetto javaserverfaces/mojarra in GitHub . È ansible trovare le istruzioni di installazione nel README.md laggiù.


    Guarda anche:

    • Quali sono i principali svantaggi di Java Server Faces 2.0?
    • Qual è la differenza tra implementazioni JSF e librerie di componenti

    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

    AGGIORNAMENTO LUGLIO 2013 : guarda la serie di articoli e l’aggiornamento per il 2013 su 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é sono basate sullo stesso standard. Il fatto che sia ansible passare da un’implementazione ad un’altra è un fatto della qualità delle specifiche dello standard JSF.

    Ma in fondo ci sono molte ragioni per cui MyFaces Core 2.x è migliore di Mojarra. Nota Sono un committer del progetto MyFaces, quindi ti darò qui solo il mio punto di vista:

    • Sono stati risolti molti problemi. Solo nel ramo 2.0.x da 2.0.0-alpha a 2.0.7 è stato chiuso 835 problemi. Ciò fornisce una misura “grezza” di quanti contributi e feedback sono stati forniti dalla comunità nel tempo. Questo è il numero di problemi chiusi nel 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

    • Community over code: la community di MyFaces conta un sacco di persone con una conoscenza eccezionale su JSF. Iscriviti alla mailing list di user e dev sono il modo migliore per sapere cosa sta succedendo, ricevere feedback e conoscere altre persone interessate a JSF. Vedi le mailing list di MyFaces

    • Apache è ben noto per prendere tutto da Sun / Oracle e renderlo migliore. In questo caso, MyFaces Core offre alcune interessanti ottimizzazioni sul risparmio parziale dello stato, sui componenti compositi e molto altro ancora.

    • MyFaces Core è compatibile con OSGi. Fornisce alcune interfacce SPI per gestire configurazioni speciali, quando è necessario un maggiore controllo sul caricamento delle classi.

    • MyFaces Core ha una migliore compatibilità con facelets 1.1.x !. Basta impostare org.apache.myfaces.REFRESH_TRANSIENT_BUILD_ON_PSS web config param su true e verrà triggersta una modalità speciale. No c: se tag o c: forEach o ui: include più rotto !. AGGIORNAMENTO MAGGIO 2012 È stato eseguito un algoritmo migliorato all’interno di MyFaces Core che riduce le dimensioni dello stato anche in parti quando si utilizzano facelet per aggiornare la struttura dei componenti in modo dinamico. Questo parametro non è più necessario.

    • MyFaces ha altri progetti (Trinidad, Tobago, Tomahawk, ExtVal, CODI, Orchestra, PortletBridge RI, ….) che aiutano a mantenere il codice in ordine, perché tutti quei progetti sono testati su MyFaces Core, e se c’è un bug, è gestito più rapidamente.

    • Puoi eseguire il checkout usando svn e creare facilmente qualsiasi progetto MyFaces, perché tutti sono basati su Maven e la maggior parte degli IDE fornisce supporto Maven.

    • Mojarra al momento attuale (JUN 2011) ha alcuni brutti bug relativi al risparmio di stato, che MyFaces non ha perché la sua implementazione è completamente diversa. Infatti, l’algoritmo di salvataggio parziale di MyFaces offre una migliore compatibilità con il salvataggio dello stato di JSF 1.2 rispetto a Mojarra. Ma nota che i ragazzi di Mojarra ci stanno lavorando, ma risolveranno che ci vorranno mesi, persino anni.

    • L’innovazione avviene su MyFaces.

    AGGIORNAMENTO MAGGIO 2012

    Vedi questo articolo 10 motivi per cui scegliere MyFaces Core come implementazione JSF per applicazioni web

    Per i ragazzi che vogliono vedere un confronto delle prestazioni tra MyFaces, Mojarra e Wicket guardano Understanding JSF 2 e Wicket: Performance Comparison

    AGGIORNAMENTO LUGLIO 2013

    Il confronto è stato esteso per includere altri framework come Spring MVC, Tapestry, Grails 2 e Wicket. Vedi l’articolo su JSFCentral: Aggiornamento JUL 2013 su JSFCentral

    Direi che non importa.

    Di recente ho avviato un progetto JSF 2.0 usando Myfaces e Primefaces. La scorsa settimana, per indagare su un bug, ho provato a eseguirlo su Mojarra. Bastava scambiare i JAR e rimuovere le voci specifiche di Myfaces in web.xml e tutto funzionava senza problemi. Certo, si trattava di un prototipo che non utilizzava tutte le funzionalità JSF, ma sono rimasto molto impressionato da questa dimostrazione di compatibilità tramite la conformità agli standard.

    Perché ho bisogno di più vasetti se utilizzo MyFaces?

    • I JAR myfaces-impl e myfaces-api sono l’equivalente di jsf-impl e jsf-api di Mojarra.
    • myfaces-bundle contiene entrambi questi per comodità, è necessario questo o gli altri due, non tutti e tre.
    • commons- * sono librerie che contengono utili funzionalità di base per gestire collezioni, bean Java, ecc. che altrimenti sarebbe necessario reimplementare (probabilmente più lento e con più bug). Molti altri progetti usano anche questi.

    In genere mi attengo all’implementazione di Mojarra a meno che non vi sia qualche motivo per andare con qualcos’altro. Io uso Netbeans, quindi è più facile utilizzare l’impostazione di progetto “predefinita” che utilizza Mojarra in esecuzione in GlassFish.

    L’ultima volta che usavo MyFaces, era perché stavo pensando di usare Tomahawk e mi sembrava ragionevole usare l’implementazione JSF dalla stessa fonte. Comunque sono passato a Primefaces e questo funziona bene con Mojarra.

    In questo momento sembra esserci un grande sviluppo in corso con le librerie di componenti JSF-2.0 in arrivo online. Quindi dovresti imparare ed essere in grado di passare tra le implementazioni JSF nel caso qualcosa vada storto.

    La ragione per cui MyFaces ha più vasi è che ha più funzionalità rispetto all’implementazione di riferimento.

    quale IDE stai usando? se usi eclipse, scarica i giare durante la creazione del progetto jsf 2.0. Controlla questo http://www.icesoft.org/training/icefaces-self-serv-training.jsf

    Non c’è molta differenza tra mojarra e MyFaces. È ansible verificare quale versione è più stabile. Come ha detto Balusc, MyFaces è la versione più stabile (nel 2005-2006). Inoltre, molte persone hanno iniziato a usare il Mojarra dopo il 2.0 perché è diventato stabile rispetto ai myfaces

    Stavo avendo gravi mal di testa con mojarra (2.2.8), comportamenti strani come i metodi ajax solo dopo la seconda interazione dell’utente a causa di precedenti aggiornamenti di moduli. Tutto finito con MyFaces.